Bug 426277 - Samba fails to enforce permissions from Fedora CIFS client
Samba fails to enforce permissions from Fedora CIFS client
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: samba (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Guenther Deschner
Depends On:
  Show dependency treegraph
Reported: 2007-12-19 13:55 EST by Steve Snyder
Modified: 2010-04-26 10:34 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-04-26 10:34:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Snyder 2007-12-19 13:55:33 EST
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):


How reproducible:


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.
Comment 1 Steve Snyder 2007-12-19 14:38:48 EST
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.


   workgroup = TESTWG
   server string = Test Samba 3.0.2x

   interfaces = lo eth0
   bind interfaces only = True
   hosts deny = all
   hosts allow = 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

   comment = Home Directory
   path = %H
   valid users = %S
   create mask = 0700
   directory mask = 0700
   volume = %U
   writeable = Yes
   browseable = No
   hide dot files = Yes

   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
Comment 2 Andrew Zabolotny 2008-01-01 04:24:45 EST
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.
Comment 3 Simo Sorce 2008-01-09 09:10:51 EST
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
Comment 4 Steve Snyder 2008-01-09 10:18:44 EST
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.

Comment 5 Steve Snyder 2008-01-09 10:25:26 EST
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.
Comment 6 Simo Sorce 2008-01-09 10:51:12 EST
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
Comment 7 Jeff Layton 2008-01-09 10:58:28 EST
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.
Comment 8 Jeff Layton 2008-11-25 08:43:08 EST
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.
Comment 9 Dmitri Pal 2010-04-26 10:34:30 EDT
Not enough info. Closing....

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