cvs commit: src/usr.bin/su su.c

[Robert Watson]

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