From: Peter Staubach <staubach@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
nfs@lists.sourceforge.net, neilb@cse.unsw.edu.au,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCH]: NFS: fix inadvertent reversion of mode bits during chown
Date: Thu, 15 Dec 2005 11:48:17 -0500 [thread overview]
Message-ID: <43A19E51.1060901@redhat.com> (raw)
In-Reply-To: <20051215163834.GB8376@hmsreliant.homelinux.net>
Neil Horman wrote:
>On Thu, Dec 15, 2005 at 09:57:24AM -0500, Trond Myklebust wrote:
>
>
>>On Thu, 2005-12-15 at 09:49 -0500, Neil Horman wrote:
>>
>>
>>
>>>I considered this, but I'm not sure thats the right way to go. It seems that the
>>>attribute structure can only set the mode bit, it has no way to represent a
>>>masking of bits. So to set the mode, the VFS needs to know what the current
>>>mode flags are. Since the sys_chown code path has no authoritative info on what
>>>the mode bits should be (like chmod does, where the user explicitly specifies
>>>the mode bits), notify_change has to rely on the current mode bits in
>>>inode->i_mode. We could modify notify_change to not alter the mode bits at all
>>>and leave the ATTR_KILL_SUID flag in the ia_valid field for individual
>>>filesystems to deal with, but I'm not sure thats the better solution, as it
>>>would still leave NFS (and all other filesystems) with the responsibility of
>>>turning the s[u|g]id bits off.
>>>
>>>
>>As far as an NFS client is concerned, we don't need to clear the
>>suid/sgid bits at all since the server will do it for us anyway. If the
>>VFS were to just send us the ATTR_UID/ATTR_GID fields, then we'd be
>>fine.
>>
>>As for local filesystems, they can be given a helper function that fixes
>>up the struct sattr to do the KILL_SUID thing.
>>
>>Cheers,
>> Trond
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>NFS maillist - NFS@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/nfs
>>
>>
>
>Then this patch should work just as well (and save the overhead of both adding
>the extra getaddr call and the need to add a helper function to all the other
>supported file systems to kill the SUID bits that already happens in the VFS.
>
I don't think that it can be quite this easy. I don't think that the
protocol
requires that the server have this behavior, so, if the client requires it,
then it will need to check to see whether the right thing happened and
if not,
then make it happen.
Perhaps the right answer is a conditional second SETATTR operation to
correct
the mode if it does not get set right when the uid/gid is changed.
Thanx...
ps
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2005-12-15 16:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-15 13:09 [PATCH]: NFS: fix inadvertent reversion of mode bits during chown Neil Horman
2005-12-15 14:14 ` Trond Myklebust
2005-12-15 14:49 ` Neil Horman
2005-12-15 14:57 ` Trond Myklebust
2005-12-15 16:38 ` Neil Horman
2005-12-15 16:48 ` Peter Staubach [this message]
2005-12-15 17:32 ` Trond Myklebust
2005-12-15 18:17 ` Neil Horman
2005-12-15 18:51 ` Trond Myklebust
2005-12-15 19:43 ` Neil Horman
2005-12-15 19:46 ` Trond Myklebust
2005-12-15 19:51 ` Neil Horman
2005-12-16 16:14 ` Neil Horman
2006-01-24 13:27 ` Neil Horman
2005-12-15 18:19 ` Peter Staubach
2005-12-15 18:56 ` Trond Myklebust
2005-12-15 19:05 ` Peter Staubach
2005-12-15 16:50 ` Trond Myklebust
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=43A19E51.1060901@redhat.com \
--to=staubach@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
--cc=nhorman@tuxdriver.com \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@zeniv.linux.org.uk \
/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.