From owner-cvs-all@FreeBSD.ORG Tue Oct 24 10:46:31 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9DEE16A407; Tue, 24 Oct 2006 10:46:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F1E043D6E; Tue, 24 Oct 2006 10:46:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0CFB846E22; Tue, 24 Oct 2006 06:46:31 -0400 (EDT) Date: Tue, 24 Oct 2006 11:46:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <453DEB1B.6040900@FreeBSD.org> Message-ID: <20061024114421.L33725@fledge.watson.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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/su su.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 10:46:32 -0000 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