Re: setfs[ug]id syscall return value and include/linux/security.h question

[Chris Wright <chris@wirex.com>]

* David Wagner (daw@mozart.cs.berkeley.edu) wrote:
> Jakub Jelinek  wrote:
> >Before include/linux/security.h was added, setfsuid/setfsgid always returned
> >old_fsuid, no matter if the fsuid was actually changed or not.
> 
> Out of curiousity:
> 
> Do you have any idea why setfsuid() returns the old fsuid, rather than
> 0 or -EPERM like all the other set*id() calls?

I agree, it seems odd.

> I find it mysterious that setfsuid()'s interface is so different.
> It is also strange that setfsuid() has no way to indicate whether the
> call failed or succeeded.  Does this inconsistency with the rest of the
> set*id() interface strike anyone else as a little odd?

You're not alone ;-)  Even the manpage suggests this is a bug.

> It is also mysterious that there is no getfsuid() call.  One has to use
> /proc to find this information.  Do you have any idea why the fsuid/fsgid
> interface was designed this way?  Is this an old kludge that we now have
> to live with, was it designed this way for a reason, or do we have the
> opportunity to fix the semantics of the interface?

I can't comment on the history of the interface.  While it's Linux
specific, I'm not sure of the legacy impact of changing the semantics of
the current interface.  Ugh.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net