aboutsummaryrefslogtreecommitdiff
path: root/Kbuild
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2008-05-22 09:33:34 -0400
committerSteve French <sfrench@us.ibm.com>2008-05-23 18:17:16 +0000
commitb0fd30d3e7e768aad5e398caaea6ae5a5c814eab (patch)
tree2841fce1397664445adad84225486d40f8c8ba97 /Kbuild
parent4468eb3fd102cad559e51594a01cbc65b994d264 (diff)
when creating new inodes, use file_mode/dir_mode exclusively on mount without unix extensions
When CIFS creates a new inode on a mount without unix extensions, it temporarily assigns the mode that was passed to it in the create/mkdir call. Eventually, when the inode is revalidated, it changes to have the file_mode or dir_mode for the mount. This is confusing to users who expect that the mode shouldn't change this way. It's also problematic since only the mode is treated this way, not the uid or gid. Suppose you have a CIFS mount that's mounted with: uid=0,gid=0,file_mode=0666,dir_mode=0777 ...if an unprivileged user comes along and does this on the mount: mkdir -m 0700 foo touch foo/bar ...there is a period of time where the touch will fail, since the dir will initially be owned by root and have mode 0700. If the user waits long enough, then "foo" will be revalidated and will get the correct dir_mode permissions. This patch changes cifs_mkdir and cifs_create to not overwrite the mode found by the initial cifs_get_inode_info call after the inode is created on the server. Legacy behavior can be reenabled with the new "dynperm" mount option. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions