Date: Tue, 24 Oct 2006 11:46:30 +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: <20061024114421.L33725@fledge.watson.org> In-Reply-To: <453DEB1B.6040900@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> <20061024105800.J37455@fledge.watson.org> <453DEB1B.6040900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Oct 2006, Maxim Sobolev wrote: > Robert Watson wrote: >> 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. > > Well unless I have confused something it is not really the case. For > example, getauid() system call takes pointer as an argument. I believe the problem is not taking a pointer as a direct argument; copyin/copyout deal with that fine. The problem is embedded pointers within data structures, causing the passed data structure to be different sizes for 32-bit/64-bit processes. I could be mistaken. > But in fact you did not answer my question. I think we should have ability > to flag the syscall as optional in the compatibility layer, just like we > have ability to do so in the native layer, so that attempt to call it > results in ENOSYS but not SIGSYS. There is no point to mandate implementing > wrapper for the otherwise optional syscall - all userland binaries that can > call it should be ready to handle ENOSYS properly, so that just returning > ENOSYS unconditionally will hurt nothing, while promoting binary > compatibility until the call gets real wrapper. Just like my own experience > with failing su(8) suggests. The real problem here is that freebsd32 remains a second class citizen, with many important system calls not implemented. For new system calls, the responsibility for that lies with the implementor (in the case of audit, me). For old ones, presumably that lies with incomplete work done in the freebsd32 compat code, and will continue to be a problem until that is fixed. 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?20061024114421.L33725>