All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Ondrej Palkovsky <ondrap@penguin.cz>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: setfsuid() and access() syscall
Date: Tue, 4 Aug 2009 16:53:09 -0500	[thread overview]
Message-ID: <20090804215309.GA15067@us.ibm.com> (raw)
In-Reply-To: <4A78A047.8040800@penguin.cz>

Quoting Ondrej Palkovsky (ondrap@penguin.cz):
> Hello,
>
> the access() syscall (to find out if the user has permission to do  
> something on file) does not seem to reflect the setfsuid() syscall.  
> There are 2 conflicting pieces of information:
>
> - kernel/sys.c:
> /*
> * "setfsuid()" sets the fsuid - the uid used for filesystem checks. This
> * is used for "access()" and for the NFS daemon (letting nfsd stay at

Good catch that.  This comment needs to be fixed (proposed patch below).

> * whatever uid it wants to). It normally shadows "euid", except when
> * explicitly set by setfsuid() or for access..
> */
> - fs/namei.c
> /*
> * access() needs to use the real uid/gid, not the effective uid/gid.
> * We do this by temporarily clearing all FS-related capabilities and
> * switching the fsuid/fsgid around to the real ones.
> */
>
> The resulting behaviour (2.6.18, 2.6.28, source code for 2.6.30 seems to  
> be the same) seems to be that access() is dependent on uid, not fsuid -  
> this seems to me to be a bug, which unfortunately somewhat inhibits  
> multithreaded file servers that want to use access() e.g. for ACL  
> checks. Is there some reason why it is implemented the way it is as it  
> looks like an intention?
>
> Best regards
> Ondrej Palkovsky

>From d0450cb216753d8c1d2d941bb5f4e15fe7aa2caf Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serue@us.ibm.com>
Date: Tue, 4 Aug 2009 16:49:46 -0500
Subject: [PATCH 1/1] fix setfsuid comment: fsuid is not used for access

Fix the comment above setfsuid which currently says that the
fsuid is used for access().  In fact, ruid is used for access.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
 kernel/sys.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index b3f1097..94e6622 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -835,9 +835,11 @@ SYSCALL_DEFINE3(getresgid, gid_t __user *, rgid, gid_t __user *, egid, gid_t __u
 
 /*
  * "setfsuid()" sets the fsuid - the uid used for filesystem checks. This
- * is used for "access()" and for the NFS daemon (letting nfsd stay at
- * whatever uid it wants to). It normally shadows "euid", except when
- * explicitly set by setfsuid() or for access..
+ * is used when setting uid for a new file, for calculating file permissions,
+ * and for the NFS daemon (letting nfsd stay at whatever uid it wants to).
+ *
+ * It normally shadows "euid", except when explicitly set by setfsuid() or
+ * for access..
  */
 SYSCALL_DEFINE1(setfsuid, uid_t, uid)
 {
-- 
1.6.0.4


      parent reply	other threads:[~2009-08-04 21:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04 20:55 setfsuid() and access() syscall Ondrej Palkovsky
2009-08-04 21:29 ` Matthew Wilcox
2009-08-05  7:57   ` Ondrej Palkovsky
2009-08-04 21:53 ` Serge E. Hallyn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090804215309.GA15067@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ondrap@penguin.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.