Permissions CIFS – Why Files in SMBFS Share Created with Executable Bit Set

cifspermissions

I mounted a samba share using the smbmount command:

$ sudo smbmount \\\\foo\\bar /mnt/bar -o user=tom

When I create new files, they get created with the executable bit set for owner, group and world. For e.g.

$ touch hello.txt 
$ ls -la hello.txt
-rwxr-xr-x 1 root root 0 Dec  2 12:28 hello.txt

The same file when created on a NFS mounted share sets up correct permissions without any executable bit set.

Why is this happening? How can it be fixed?

Best Answer

NFS was invented in the Unix world and so understands traditional Unix permissions out of the box. (The ACL of modern unix systems are another matter, but recent implementations of NFS should cope with them.)

Samba was invented in the IBM/Microsoft PC world, to exchange files with systems that had no permissions beyond read-only/read-write. It is now native to Windows. By default, Samba does not transmit Unix permissions. Depending on the configuration, either all files are marked executable (which is annoying) or all files (except directories) are marked non-executable (which is annoying).

There are various extensions to the Samba/CIFS protocol that make it more suited for Unix use. Try enabling Unix extensions in the server configuration:

[global]
unix extensions = yes

Related Solutions

Different Hard Link Permissions Behavior in CentOS 6 vs CentOS 7

I spun up some fresh CentOS 6 and 7 vm's and was able to recreate the exact behavior you showed. After doing some digging, it turns out that this is actually a change in the kernel regarding default behavior with respect to hard and soft links for the sake of security. The following pages pointed me in the right direction:

http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415

http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1

If you make the file world writable, your admin user will be able to create the hard link.

To revert to the behavior of CentOS 6 system wide, new kernel parameters were added. Set the following in /etc/sysctl.conf:

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

then run

sysctl -p

As for why your program opts to use links instead of copying files, why create an exact copy of a file you need to use when you can just create an entry that points to the original blocks? This saves disk space and the operation is less costly in terms of CPU and I/O. The new hard link is the same file, just with different metadata/inode. If you were to delete the original file after creating a hard link, it won't affect the link. A file is only 'deleted' once all links have been removed.

Ubuntu – Why would a directory have the sticky bit set without the executable bit

From the manual page for sticky:

STICKY DIRECTORIES

A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

Any user may create a sticky directory. See chmod(1) for details about modifying file modes.

The upshot of this is that only the owner of a file in a sticky directory can remove the file. In the case of the cron tables, this means that I can't go in there and remove your cron table and replace it with one of my choosing, even though I may have write access to the directory. It is for this reason that /tmp is also sticky.

Best Answer

Related Solutions

Different Hard Link Permissions Behavior in CentOS 6 vs CentOS 7

Ubuntu – Why would a directory have the sticky bit set without the executable bit

Related Question