From owner-cvs-src@FreeBSD.ORG Tue Oct 24 10:02:33 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 021D616A412; Tue, 24 Oct 2006 10:02:33 +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 C0D4B43D5C; Tue, 24 Oct 2006 10:02:25 +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 187A146CFF; Tue, 24 Oct 2006 06:02:25 -0400 (EDT) Date: Tue, 24 Oct 2006 11:02:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <453DE26E.3040502@FreeBSD.org> Message-ID: <20061024105800.J37455@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> 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 10:02:33 -0000 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