Re: inode_change_ok

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Trond Myklebust wrote:

CAP_CHOWN would therefore only be useful in the corner case where the
server is allowing full root privileges to a client, and where the
client is using capabilities to limit the root account's (or a setuid
processes') ability to exercise those full privileges.

Cheers,
 Trond


It sounds like I do need to make the change to cifs to add the optional (based on the mount parm the admin can choose which model) call to inode_change_ok to make the permissions check consistent when "noperm" is not enabled on that mount , but I was trying to figure out how important that change to the cifs code was and whether it was a priority to get in. I realize that this corner case is far less common in the wild for nfs. The corner case you describe above did seem to come up today for cifs though (where the admin had in effect, trusted the client, and allowed the client to mount as root with full root priv on the server - I can imagine this being valid in their particular case, with a trusted client os, over a trusted lan, but obviously would not be the most common scenario). Obviously they did not turn on multiusermount in /proc/fs/cifs (ie the ability to send different uids on the wire depending on the uid of the client calling process) so the only perm check that would be useful that was occuring at the client the way they had chosen to configure/mount was happening in generic_permission in the client. In their particular configuration open and other paths in the vfs that call permission behaved fine and the permission checks worked as expected - but chown always worked (which is of course wrong) since the vfs does not call permission but expects the vfs (if at all) to call inode_change_ok - so open failing, but chown working was confusing to them.

Of course it does not make it much easier trying to compare with other filesystems - ncpfs does seem to call both (generic_permission inode_change_ok) and but the afs model (openafs) is far more complicated and somewhat confusing (and interestingly afs does not call generic_permission but does call inode_change_ok) so it is not really possible to draw too many conclusions for how afs approached the same two usage models (apparently afs also had a third usage model based on machine address)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux