Messages in this thread | | | From | (David Wagner) | Subject | Re: setfs[ug]id syscall return value and include/linux/security.h question | Date | 26 Mar 2003 23:33:08 GMT |
| |
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/
| |