Description of problem: While testing bug #253314 (CVE-2007-3740 CIFS should honor umask), it was observed that when invoke mkdir(2) call on a CIFS fs, there is still a window of time between dir remote creation and umask has been applied. Therefore, another user can access the directory, even if he should not be allowed. Version-Release number of selected component (if applicable): kernel: 2.6.18-8.1.10.el5 How reproducible: always Steps to Reproduce: 1. mount a CIFS fs on /mnt/tmp with the following options, * unix extensions = yes * directory mask = 0777 2. compile and run the program in attachment. Actual results: umask 777 mkdir. drwxrwxrwx 2 root root 0 Sep 11 05:59 /mnt/tmp/new (sleep a second) d--------- 2 root root 0 Sep 11 05:59 /mnt/tmp/new Expected results: umask 777 mkdir. d--------- 2 root root 0 Sep 11 05:59 /mnt/tmp/new Additional info:
Created attachment 193311 [details] reproducer
I was also able to see this problem from the shell: # ( rmdir foo; umask 077; mkdir foo; ls -ld foo; sleep 1; ls -ld foo ) rmdir: `foo': No such file or directory drwxr-xr-x 2 testuser testuser 0 Sep 12 08:10 foo drwx------ 2 testuser testuser 0 Sep 12 08:10 foo Interestingly, it only seems to occur in the mkdir codepath. Creating normal files don't seem to show the problem.
I think the issue is that the order of operations is something like this: Send mkdir command to server Get inode info from server instantiate dentry and inode set attributes (particularly the mode) because we're fetching the inode info before setting the mode, the cache ends up having the inode attrs as they exist before the mode is set. The next revalidation fixes it, but there is a small race window. While we could reorder these operations so that this window is closed on the client, there's *still* a race window between the mkdir and setattr. Another host could get into the directory regardless of how quickly we do these changes. The upstream code now has support for a POSIX mkdir, which allows setting the mode at creation time and that should close this everywhere. Unfortunately, it seems somewhat borked at the moment, as the umask isn't applied correctly. I'll open a new BZ for that and see if we can't get that fixed before the next set of update cycles.
Ok, I got a patch in upstream that makes POSIX mkdir respect the umask. When dealing with servers that don't support that call, but that do support "traditional" SFU extensions, this window really can't be closed. We could, of course, fake up the mode locally to match what it will eventually be. This is deceptive though, since the mode on the server wouldn't see this change until after to setattr went out onto the wire. So that would close this hole on this particular client, but a different machine (or something on the server) could race in after the mkdir and get access to the dir before the mode was set. I think this is likely a CANTFIX sort of problem, unless you count using POSIX mkdir as a fix for it.
The update that I'm planning for RHEL5.2 should fix this on servers that support POSIX mkdir. If you're able, you may want to test the kernels on my people page: http://people.redhat.com/jlayton ...and see if they fix this for you. Note that for servers that don't support posix mkdir, this can't be fixed since it's a protocol problem.
Confirmed kernel-2.6.18-58.el5.jtltest.18.i686.rpm fixed the problem.
I've proposed an update of CIFS to a newer upstream rev for 5.2, so I'm going to fold this BZ into that one. *** This bug has been marked as a duplicate of 417961 ***