Date: Tue, 24 Oct 2006 02:52:46 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Robert Watson <rwatson@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: <453DE26E.3040502@FreeBSD.org> In-Reply-To: <20061024104143.Y37455@fledge.watson.org> References: <200610240818.k9O8IATH022313@repoman.freebsd.org> <20061024094643.N37455@fledge.watson.org> <453DDED4.3070208@FreeBSD.org> <20061024104143.Y37455@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?453DE26E.3040502>