Red Hat Bugzilla – Bug 426277
Samba fails to enforce permissions from Fedora CIFS client
Last modified: 2010-04-26 10:34:30 EDT
Description of problem: The file-creation permissions specified for the Samba server are not honored when files are written by a Fedora7 CIFS client. Version-Release number of selected component (if applicable): samba-3.0.25b-1.el5_1.4 How reproducible: Always Steps to Reproduce: 1. Configure Samba server on RHEL 5.1 with 2 shares, each specifying different file permissions 2. Mount both shares on a Fedora7 system using the CIFS filesystem 3. Copy file with and without the "-p" (preserve switch) and note that the permisions specified on the server are not honored. Actual results: Permissions on newly-created files are not what they are specified to be. Expected results: If a specified set of permissions is specified in the Samba server configuration, then those permisions should be honored. Additional info: May be a security-sensitive matter if Samba file permissions are relied upon. Detailed config info and testing methodology to follow.
My Samba configuration is below. The significant part is that files written to the "public" share should have 666 permissions set while files written to user home shares should have only the user-specific permissions set. The permissions were handled correctly with the Samba server on a RHEL 4.5 system (same CIFS client). Since upgrading to RHEL v5.1 they do not. The shares are mounted on a fully-updated Fedora7 system like this: //nemesis/steve /mnt/cifs/myhome cifs credentials=/etc/fstab.cifs 0 0 //nemesis/public /mnt/cifs/public cifs credentials=/etc/fstab.cifs 0 0 Client: these are the permissions on the file used for testing: $ ll testfile -rw-r--r-- 1 steve users 22 2007-12-19 13:05 testfile Client: start with no files on the shares: $ for d in myhome public ; do rm -f /mnt/cifs/$d/testfile; done Client: copy without attributes preserved, then look at files created: $ for d in myhome public ; do cp testfile /mnt/cifs/$d/; done $ ll /mnt/cifs/myhome/testfile /mnt/cifs/public/testfile -rwxr--r-- 1 steve users 22 2007-12-19 14:07 /mnt/cifs/myhome/testfile -rw-rw-rw- 1 steve users 22 2007-12-19 14:07 /mnt/cifs/public/testfile Note that the 600 permission that should be applied to user shares was not. Instead the file has a 744 set of permissions. What happened here is that the "create mask" parameter was not honored. The group- and world-readable bits should have been masked out because only the user bits have been specified in the Samba config as valid. That's the first error. Erase those files in preparation for the next test. $ for d in myhome public ; do rm -f /mnt/cifs/$d/testfile; done Now I'll attempt to create those files again, this time specifiying that I want the original client permissions preserved. The preservation should not be honored because the server has been configured with its own permissions standards. $ for d in myhome public ; do cp -p testfile /mnt/cifs/$d/; done cp: setting permissions for `/mnt/cifs/myhome/testfile': Permission denied cp: setting permissions for `/mnt/cifs/public/testfile': Permission denied $ ll /mnt/cifs/myhome/testfile /mnt/cifs/public/testfile -rwx------ 1 steve users 22 2007-12-19 13:05 /mnt/cifs/myhome/testfile -rw--w--w- 1 steve users 22 2007-12-19 13:05 /mnt/cifs/public/testfile Here we see another 2 errors. First, the file on the user home share now has the user-executable permission set. How? We started out with 644 and specified a mask of 700 bits. So the final set of permissions should be 600, the original user-read and user-write bits and nothing else. The other problem is that the permissions on the public share are completely screwed up. That 644 file when copied to the public shared should have had 666 permissions forced upon it by the "force create mode" parameter of the public share definition. Instead, the group- and world-readable bits were lost. So that is a total of 3 errors in the setting of permissions on the Samba shares. The inability to specify file permissions on Samba shares is a big problem. I want to note again that the file permissions were handled correctly in RHEL 4.5. Please fix this soon. Thanks. --------------------------------------------- [global] workgroup = TESTWG server string = Test Samba 3.0.2x interfaces = lo eth0 bind interfaces only = True hosts deny = all hosts allow = 127.0.0.1 192.168.0. dns proxy = yes netbios name = nemesis name resolve order = hosts wins bcast wins support = yes max log size = 1024 log file = /var/log/samba/%m.log security = user passdb backend = tdbsam null passwords = yes guest account = smbguest encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd os level = 65 local master = yes domain master = yes preferred master = yes time server = yes socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 [homes] comment = Home Directory path = %H valid users = %S create mask = 0700 directory mask = 0700 volume = %U writeable = Yes browseable = No hide dot files = Yes [public] comment = All Users path = /home/samba/public create mask = 0666 force create mode = 0666 directory mask = 0777 force directory mode = 0777 guest ok = Yes writeable = Yes
I'm not sure but it looks like your bug is similar to mine. Please take a look at bug #221081 and perhaps you could try the recipe that helped me, but you will have to recompile cifs.ko for this.
Not sure it is the same. Steve, can you try disabling unix extensions and remounting on the client side an report if anything changes for you in that case? *disables unix extensions: echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled
As root: # umount /mnt/cifs/public/ # umount /mnt/cifs/myhome/ # echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled # mount /mnt/cifs/myhome/ # mount /mnt/cifs/public/ As user, create test file: $ touch testfile $ ll testfile -rw-r--r-- 1 steve users 0 2008-01-09 09:41 testfile As user, 1st test (no preservation) $ for d in myhome public ; do rm -f /mnt/cifs/$d/testfile; done $ for d in myhome public ; do cp testfile /mnt/cifs/$d/; done $ ll /mnt/cifs/myhome/testfile /mnt/cifs/public/testfile -rw-r--r-- 1 root root 0 2008-01-09 09:42 /mnt/cifs/myhome/testfile -rw-r--r-- 1 root root 0 2008-01-09 09:42 /mnt/cifs/public/testfile As user, 2nd test (preserve attributes): $ for d in myhome public ; do rm -f /mnt/cifs/$d/testfile; done $ for d in myhome public ; do cp -p testfile /mnt/cifs/$d/; done cp: preserving times for `/mnt/cifs/myhome/testfile': Operation not permitted cp: preserving times for `/mnt/cifs/public/testfile': Operation not permitted $ ll /mnt/cifs/myhome/testfile /mnt/cifs/public/testfile -rw------- 1 root root 0 2008-01-09 09:43 /mnt/cifs/myhome/testfile -rw------- 1 root root 0 2008-01-09 09:43 /mnt/cifs/public/testfile Disabling the Unix extensions gives results that are different but still not correct. I will continue to refer to the smb.conf shown above. In the first test, the file on the user share should be 600 (644 on client, but server should mask only bits 700). On the public share the file should be 666 (644 on client, but "force create mode" in Samba config should make it 666). In the second test, the file on the user share is correct (client: 644; mask 700; result 600). With the file on the public share we see again that "force create mode" is not enforced (client: 644; force perm: 666; result s/b 666, is 600). BTW, doing the above steps on a Fedora7 client but RHEL 4.6 server I get the same results. Same Samba config on both servers, but "samba-3.0.25b-1.el5_1.4" on one and "samba-3.0.25b-1.el4_6.4" on the other. FYI.
One more thing. It occurred to me that maybe the client's view of the file permissions was wrong. That is, the permissions were set correctly on the server but incorrectly seen from the client's perspective. No. The view of the created files, both user and public, on the server machine shows the same permissions as seen on the shares from the client. (Owner on the server is shown correctly, but seen as root on client due to root having mounted the shares.) FYI, again.
Thanks, I am wondering if the permissions are changed by cp after the file creation. IIRC "force create mode" works only on file creation, but will not force anything if a chmod is done on the file later. It seem although that unix extensions are doing something wrong, need to investigate on which side of the fence, smbd or cifs.ko
With unix extensions disabled, the behavior you're seeing may be the same as the problem in bug 221081. It might be interesting to build a F7 kernel with the patch in that BZ, and see if the behavior is different. I'm dusting that patch off today and testing it myself, so I may try again to get it upstream.
Is this still an issue with current Fedora clients(2.6.26-ish? There were a number of changes to how mode bits are handled in upstream kernels, so the results here might now be different.
Not enough info. Closing....