* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:26 EST