Messages in this thread | | | Date | Wed, 26 Mar 2003 17:56:00 -0800 | From | Chris Wright <> | Subject | Re: setfs[ug]id syscall return value and include/linux/security.h question |
| |
* 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/
| |