[linux-cifs-client] [PATCH 0/7] [CIFS] stop faking up permissions when the server doesn't support it

Jeff Layton jlayton at redhat.com
Mon May 5 19:16:21 GMT 2008

Simo and I brought this up a few months ago, but I've just recently come
up with a more comprehensive patch for it.

CIFS allows inodes to have permissions that are not and cannot be stored
on the server. When unix permissions are not negotiated and cifsacl
isn't enabled, the cifs client will allow userspace to change the
ownership and mode of an inode. These permissions are not stored on the
server. If the inode is pushed out of the cache, this information is

This can happen in two different ways:

1) unmounting and mounting a share (or rebooting the client) can cause
the inode to pick up the default file/dir mode of the share.

2) memory pressure. Here's an easy reproducer. Mount up a CIFS share w/o
unix extensions on a box with 512M of memory. Create a file on the share
and set its mode to something besides the file_mode of the share.

    # touch /mnt/cifs/testfile.txt
    # chmod 0644 /mnt/cifs/testfile.txt 

...increase the vfs_cache_pressure (I've been able to reproduce this problem without this, but it makes the reproducer more reliable):

    # echo 1000 > /proc/sys/vm/vfs_cache_pressure

...now, dd a file to the share that will exert memory pressure:

    # dd if=/dev/zero of=/mnt/cifs/testfile2.txt bs=4k count=262144

...when it completes, check the mode of the first file again. In many
cases, it will have reset. We can *never* be 100% sure that this mode
will stick. This is entirely unpredictable -- it could happen at any

Another problem here is that when creating a file, only the mode is
preserved. The uid/gid of the creator isn't. This essentially means that
we're allowing userspace processes to create files and directories with
arbitrary modes that are owned by a different user. While I've not been
successful in exploiting this, it seems risky to me. It's also
problematic. If I create a directory or file with a restrictive mode,
then I may not have permissions to access it since I don't own it.

Finally, things like the setgid bit on the parent directory are not
respected. We may not have enough information to actually set the mode
correctly, even if we did just want to set it in the local inode cache.

Even if this somehow helps some apps to work or test suites to pass,
inconsistent behavior like this is very risky. It's better to just
break apps that are depending on this behavior than to have apps that
work 99% of the time with this and then unpredictably break the other 1%
of the time. We can't overstate the value of consistent behavior when it
comes to building reliable systems.

This patchset is an attempt to correct this behavior. It basically makes
it so that when unix extensions and cifsacl are disabled, that we
make all inodes have the file/dir mode of the share. The main exception
is the ATTR_READONLY bit. The patchset adds some special handling for
that to attempt to reflect this in the mode. We had some special
handling of it before, but it was a bit inconsistent.

Signed-off-by: Jeff Layton <jlayton at redhat.com>

More information about the linux-cifs-client mailing list