Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

So you did

setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share

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

chmod 2770 share

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.

share|improve this answer
    
Well explained, I'm pretty new to this level of Linux and you've cleared it up for me. Thank you. –  malco Oct 23 '12 at 7:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.