Failed to set gid privileges

[Peter Samuelson]

[Dave C-B]
> 	The Multics approach was to trap on the invalid call,
> 	and tell the human that the program needed a library
> 	containing, in this case, setresgid()
> 
> 	We do the same thing (finally ^$%^$%#^!!!) on Solaris,
> 	and I wonder if we can't arrange to do the same thing
> 	on Linux.

The Linux libc (glibc, as they say) already does quite a bit of this,
internally.  There are a lot of functions (the whole pthreads library,
for one) which can be implemented in different ways depending on what
facilities are available at runtime.

This really should be extended to libc system calls -- at least in the
cases where new syscalls can be correctly emulated by old.  The problem
comes in where a new syscall cannot be 100% emulated, in which case a
mostly-correct implementation would likely be rejected as doing more
harm than good.  (The glibc people take correctness *very* seriously.)

> 	The arguably proper place to fix this is in the linker,
> 	but that's famously not under the controll of the Samba
> 	team (;-)).

The linker shouldn't need to get involved.  It's not like we have an
unresolved symbol here: it's an unresolved *syscall*, which libc should
be able to handle if there's a good way to emulate it.  Without loading
up an emergency shim library, though I suppose that could work too....

> 	Hmmn: what is the errno value returned?  It should be
> 	ENOTSUP, "Operation not supported".  If it is, Samba
> 	can be taught to produce the proper error message...

Actually I think it will get ENOSYS, "Function not implemented".
Either way, I agree that Samba should report it via strerror().

Peter