From owner-cvs-src@FreeBSD.ORG Tue Oct 24 09:53:49 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 096AC16A403; Tue, 24 Oct 2006 09:53:49 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8808343D45; Tue, 24 Oct 2006 09:53:48 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.6) with ESMTP id k9O9rj4S020796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 02:53:46 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <453DE26E.3040502@FreeBSD.org> Date: Tue, 24 Oct 2006 02:52:46 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Robert Watson References: <200610240818.k9O8IATH022313@repoman.freebsd.org> <20061024094643.N37455@fledge.watson.org> <453DDED4.3070208@FreeBSD.org> <20061024104143.Y37455@fledge.watson.org> In-Reply-To: <20061024104143.Y37455@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 09:53:49 -0000 Robert Watson 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? -Maxim