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 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?
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?
-
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