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

[Robert Watson]

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