Bug 287401 - Delay between dir remote creation and umask applied on CIFS fs
Summary: Delay between dir remote creation and umask applied on CIFS fs
Status: CLOSED DUPLICATE of bug 417961
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jeff Layton
QA Contact: Martin Jenner
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-12 09:39 UTC by Qian Cai
Modified: 2007-12-19 16:44 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-12-19 16:44:49 UTC

Attachments (Terms of Use)
reproducer (830 bytes, text/plain)
2007-09-12 09:39 UTC, Qian Cai
no flags Details

Description Qian Cai 2007-09-12 09:39:38 UTC
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:

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
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
d--------- 2 root root 0 Sep 11 05:59 /mnt/tmp/new

Additional info:

Comment 1 Qian Cai 2007-09-12 09:39:38 UTC
Created attachment 193311 [details]

Comment 2 Jeff Layton 2007-09-12 12:13:22 UTC
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.

Comment 3 Jeff Layton 2007-09-12 14:07:56 UTC
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.

Comment 4 Jeff Layton 2007-09-21 13:31:57 UTC
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.

Comment 5 Jeff Layton 2007-12-11 13:57:21 UTC
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:


...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.

Comment 6 Qian Cai 2007-12-18 07:05:50 UTC
Confirmed kernel-2.6.18-58.el5.jtltest.18.i686.rpm fixed the problem.

Comment 7 Jeff Layton 2007-12-19 16:44:49 UTC
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 ***

Note You need to log in before you can comment on or make changes to this bug.