To: linux-kernel@vger.kernel.org
Path: not-for-mail
From: daw@mozart.cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.linux-kernel
Subject: Re: setfs[ug]id syscall return value and include/linux/security.h question
Date: 26 Mar 2003 23:33:08 GMT
Organization: University of California, Berkeley
Distribution: isaac
Message-ID: <b5tdbk$hoj$1@abraham.cs.berkeley.edu>
References: <20030326181509.Q13397@devserv.devel.redhat.com>
NNTP-Posting-Host: mozart.cs.berkeley.edu
NNTP-Posting-Date: 26 Mar 2003 23:33:08 GMT
Originator: daw@mozart.cs.berkeley.edu (David Wagner)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1153
Lines: 19

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/