Bug 287401 - Delay between dir remote creation and umask applied on CIFS fs
Delay between dir remote creation and umask applied on CIFS fs
Status: CLOSED DUPLICATE of bug 417961
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Layton
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2007-09-12 05:39 EDT by CAI Qian
Modified: 2007-12-19 11:44 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-19 11:44:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description CAI Qian 2007-09-12 05:39:38 EDT
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 CAI Qian 2007-09-12 05:39:38 EDT
Created attachment 193311 [details]
Comment 2 Jeff Layton 2007-09-12 08:13:22 EDT
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 10:07:56 EDT
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 09:31:57 EDT
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 08:57:21 EST
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 CAI Qian 2007-12-18 02:05:50 EST
Confirmed kernel-2.6.18-58.el5.jtltest.18.i686.rpm fixed the problem.
Comment 7 Jeff Layton 2007-12-19 11:44:49 EST
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.