Date: Tue, 24 Oct 2006 11:02:25 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/su su.c Message-ID: <20061024105800.J37455@fledge.watson.org> In-Reply-To: <453DE26E.3040502@FreeBSD.org> References: <200610240818.k9O8IATH022313@repoman.freebsd.org> <20061024094643.N37455@fledge.watson.org> <453DDED4.3070208@FreeBSD.org> <20061024104143.Y37455@fledge.watson.org> <453DE26E.3040502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Oct 2006, Maxim Sobolev wrote: >> On Tue, 24 Oct 2006, Maxim Sobolev wrote: >> >>> OK, in this particular case I am trying to run su(8) binary compiled for >>> FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't really >>> make any difference since the code is the same). >>> >>> Since all audit syscalls in freebsd32 emulation layer are redirected to >>> nosys() any attempt to invoke such syscall results in both ENOSYS errno >>> *and* SIGSYS signal delivered to the process in question. The latter kills >>> the process without giving it any chance to handle ENOSYS. >> >> So the actual bug here is that there's no compat32 definitions for the >> audit system calls. I have a suspicion that we may need compat32 wrappers >> in some cases, but you could start by simply exposing the audit system >> calls in compat32 by changing UNIMPL to STD (or MSTD in RELENG_6)? > > Shouldn't unimplemented syscall have the same semantics in binary > compatibility mode and in native mode (i.e. ENOSYS, but not SIGSYS)? That's > my biggest confusion. Why do we get just ENOSYS in native mode when audit is > not in, while ENOSYS+SIGSYS in compatibility mode? The method by which the distinction between ENOSYS+SIGSYS and plain ENOSYS is determined is in the implementation of the system call. If a system call is flagged as unimplemented (i.e., you never hit the function implementing it), you get SIGSYS+ENOSYS. If you enter the stub, you get ENOSYS. So the problem is that the compat code doesn't enter the stub, so never gets to the ENOSYS path. A casual glance at the system call arguments for audit suggest that wrappers aren't needed (no pointers embedded in structure arguments), so simply marking them as implemented will likely work. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061024105800.J37455>