Re: inode_change_ok

Re: inode_change_ok

[Trond Myklebust]

On Mon, 2005-11-28 at 11:48 -0600, Steve French wrote:
> Why are there no calls to inode_change_ok in nfs (on the client), but 
> there are in most other filesytsems?   Seems like there are some cases 
> in nfs in which a local permission check is done via  a call to 
> nfs_permission which calls generic_permission ... if that is the case 
> why not do a call to inode_change_ok in similar cases?

Under the NFS model, the server manages the permissions, not the client.

The purpose of inode_change_ok() is to perform a load of local checks
which are simply alien to that model: 

 a) your capabilities don't mean anything to the server. Its decision to
grant the ability to change owner of a file is based on your
credentials, not your capabilities.

 b) Even the uid/gid checks don't take into account the fact that the
server may be mapping you into different users/groups (c.f. root
squashing etc.).

All, in all, a call to inode_change_ok() would at best be redundant, and
at worst, be plain incorrect.

Cheers,
  Trond

Re: inode_change_ok

[Trond Myklebust]

On Mon, 2005-11-28 at 12:06 -0500, Trond Myklebust wrote:
> On Mon, 2005-11-28 at 11:48 -0600, Steve French wrote:
> > Why are there no calls to inode_change_ok in nfs (on the client), but 
> > there are in most other filesytsems?   Seems like there are some cases 
> > in nfs in which a local permission check is done via  a call to 
> > nfs_permission which calls generic_permission ... if that is the case 
> > why not do a call to inode_change_ok in similar cases?
> 
> Under the NFS model, the server manages the permissions, not the client.
> 
> The purpose of inode_change_ok() is to perform a load of local checks
> which are simply alien to that model: 
> 
>  a) your capabilities don't mean anything to the server. Its decision to
> grant the ability to change owner of a file is based on your
> credentials, not your capabilities.
> 
>  b) Even the uid/gid checks don't take into account the fact that the
> server may be mapping you into different users/groups (c.f. root
> squashing etc.).
> 
> All, in all, a call to inode_change_ok() would at best be redundant, and
> at worst, be plain incorrect.

BTW: The call to permission() is thoroughly redundant too, and really
wants to be optimised away. Permissions checking is done by the server
on the actual SETATTR RPC call...

Cheers,
  Trond

inode_change_ok

[Steve French]

Why are there no calls to inode_change_ok in nfs (on the client), but 
there are in most other filesytsems?   Seems like there are some cases 
in nfs in which a local permission check is done via  a call to 
nfs_permission which calls generic_permission ... if that is the case 
why not do a call to inode_change_ok in similar cases?

For the case of cifs vfs, which is also missing this call - I was 
thinking of adding something like:
       if (!cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_PERM)
             inode_change_ok(direntry->d_inode, attrs);
to fs/cifs/inode.c near the beginning of cifs_setattr.   Although the 
permissions (actually ACLs) are checked on the server during setattr 
from cifs to Samba or cifs servers such as Windows, it is common for 
convenience for users to mount with one id, rather than authenticating 
each user (so that there are multiple smb uids) in which case the 
permission check on setattr on the client can be important since 
apparently the ".permission" entry point does not seem to get invoked in 
the chown/chmod path.