I have a question/confusion regarding forcing inherited permissions on Linux (namely CentOS 6)
The Setup:
1 x CentOS File Server
2 x CentOS NFS Clients
Lots x Windows Samba Clients
The file share is /srv/share shared with both Samba and NFS local permissions are as follows:h
drwxrwx---. 2 root sharegroup 4.0K Oct 22 14:41 share
All UIDs/GIDs unified through Active Directory, the primary group for all users is 'sharegroup'.
NFS client mounted in fstab as:
tst-lnx03:/srv/share /mnt/share nfs defaults 0 0
Windows box through UNC path:
\\tst-lnx03\share
What I Would Like:
Anything written/created in the /srv/share folder regardless of whether it came through NFS or Samba to be say 770 root sharegroup.
What I Have Tried:
I have tried using ACLs:
setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share
With the result:
ls -lah
-rwxrwx---+ 1 testuser11 sharegroup 0 Oct 22 14:25 tu12-smb-win
-rw-rw----+ 1 testuser2 sharegroup 0 Oct 22 14:23 tu2-local-local
-rw-r-----+ 1 testuser4 sharegroup 0 Oct 22 14:24 tu4-NFS-lnx04
I have tried using sticky bits:
chmod 2770 share
With the result:
ls -lah
-rwxr--r-- 1 testuser11 k8 sharegroup 0 Oct 22 14:38 tu12-smb-win
-rw-r--r-- 1 testuser2 k8 sharegroup 0 Oct 22 14:38 tu2-local-local
-rw-r--r-- 1 testuser4 k8 sharegroup 0 Oct 22 14:38 tu4-NFS-lnx04
Confusion
Looks like setfacl is the winner but am slightly confused by the output, why does the sticky bit version add in a random other read and strip the write off group?
I think I can attribute the NFS created file being different due to the default umask of 0022 but not the other changes. I would have expected the windows created and the locally created files to match for permisions too.
Can anyone explain what's happening in each case? I'm a little perplexed. If you need anything more from me just shout and I'll put it up.
Best Answer
So you did
Anything you do with
setfacl d:(known as "default ACL") does not impact ownership, only the accessibility. So you can decide "who can access", but not "who owns". You've just caused the test files to have rwx access for the owning user and for root; and rwx access for the owning group and for the "sharegroup". But the owning user and owning group were determined exactly the same way as without setfacl.The permissions of files are unexpected, because with setfacl'd file, the umask is no longer taken into account. Each file has its "own umask", known simply as mask (see
getfacl).And you did
Wrong again. 2770 is not sticky, this is setgid bit. Sticky would have been 1770. The setgid changed the owning group for the new files, and did not impact their permissions at all. The permissions, as usual, take into account umask (see
umask) and mode suggested by application creating the file.I'm not aware how can the thing you require be properly implemented with the tools you have. There is no "setuid for directories" implemented in Linux.