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

[Maxim Sobolev]

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.

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.

-Maxim