Re: [PATCH]: NFS: fix inadvertent reversion of mode bits during chown

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>On Thu, 2005-12-15 at 11:48 -0500, Peter Staubach wrote:
>
>  
>
>>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.
>>    
>>
>
>That still allows for dangerous races in which client applications may
>suddenly find themselves authorised to suid/sgid to the new uid/gid. Any
>server that does this should probably be mounted using the nosuid mount
>option and simply not be used for setuid/setgid applications.
>
>As I see it, there are 2 possible options here:
>
> 1) Rely on cached attributes and explicitly clear the suid/sgid mode
>bit (which is what we do now).
> 2) Rely on the server clearing the suid/sgid mode bit.
>
>Trying to fix up the mode to be set inside the filesystem code is an
>unacceptable practice since we cannot know who the caller is, or what
>the intentions were.
>

It seems to me that there is a third option.  That would be to provide the
proper synchronization to prevent such races.  Any callers wishing to use
either the mode or owners of the file should have validated the attributes
first, and if there is such a setuid/setgid operation going on, then block
them until that operation has completed.  Perhaps something like the
revalidate hook can be used by the NFS client to synchronize things.

We already know that it is not safe to combine changing the mode and the
uid or gid in a single NFS SETATTR request.  The server may or may not allow
the owners to be changed and so, may or may not perform the mode change.  In
fact, it is not terribly safe to combine changing the uid or gid with any
other attributes in a single call.  This is an unfortunate fact of life
when attempting to be interoperable across a large variety of platforms.

    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