[lkml]   [2003]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: setfs[ug]id syscall return value and include/linux/security.h question
* David Wagner ( 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.

Linux Security Modules
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean