Bug 287401
| Summary: | Delay between dir remote creation and umask applied on CIFS fs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Qian Cai <qcai> | ||||
| Component: | kernel | Assignee: | Jeff Layton <jlayton> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.0 | CC: | staubach, steved | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-12-19 16:44:49 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Qian Cai
2007-09-12 09:39:38 UTC
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. |