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
prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).