91

I have a directory called data. Then I am running a script under the user id 'robot'. robot writes to the data directory and update files inside. The idea is data is open for both me and robot to update.

So I setup the permission and owner group like this

drwxrwxr-x  2 me robot-grp 4096 Jun 11 20:50 data

where both me and robot belongs to the 'robot-grp'. I change the permission and the owner group recursively like the parent directory.

I regularly upload new files into the data directory using rsync. Unfortunately, new files uploaded does not inherit the parent directory's permission as I hope. Instead it looks like this

-rw-r--r-- 1 me users       6 Jun 11 20:50 new-file.txt

When robot tries to update new-file.txt, it fails due to lack of file permission.

I'm not sure if setting umask helps. In anycase the new files does not really follow it.

$ umask -S
u=rwx,g=rx,o=rx

I'm often confounded by Unix file permission. Do I even have a right plan? I'm using Debian lenny.

Jens Erat
  • 17,897
Wai Yip Tung
  • 1,011
  • 1
  • 8
  • 5

4 Answers4

59

You do not want to change your system's default umask, that is a security risk. The sticky bit option will work to some extent, but using ACL's is the best way to go. This is easier than you think. The problem with basic ACL's is that they are not recursive by default. If you set an ACL on a directory, only the files inside that directory inherit the ACL. If you create a subdirectory, it does not get the parent ACL unless the ACL is set to recurse.

First, make sure ACLs are enabled for the volume the directory is on. If you have tune2fs, you can perform the following:

# tune2fs -l /dev/sda1 | grep acl
Default mount options:    user_xattr acl

If you don't have tune2fs, then examine fstabs:

# cat /etc/fstab 
/dev/system/root        /                       ext3    defaults        1 1
/dev/system/home        /home                   ext3    defaults        1 2
/dev/storage/data       /data                   ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2

The 4th column that says "defaults" means on my system (CentOS 5.5), ACL's are on. When in doubt, leave it as defaults. If you try to set the ACL and it errors out, go back and add the acl option to /etc/fstab right after defaults: defaults,acl.

From what I understand, you want everyone in the users group to have write access to the data directory. That's accomplished by the following:

setfacl -Rm g:users:rwX,d:g:users:rwX data/
jww
  • 12,146
  • 46
  • 125
  • 210
churnd
  • 5,008
  • 1
    I used this command but it didn't fix my problem, how can i undo this command please? – Itai Ganot Aug 15 '13 at 09:37
  • Did the trick on ubuntu with sudo setfacl -Rm g:users:rwX,d:g:users:rwX /var/www/logs_or_something. Had problem with PHPUnit tests. After creating log files from running tests apache user www-data couldn't write/read them. – s3m3n Aug 26 '13 at 10:12
  • 2
    @Itai Ganot - according to the setfacl man page, -b or --remove-all removes the extended ACLs. – jww Apr 03 '14 at 00:09
  • So, you would just append setfacl -Rm g:users:rwX,d:g:users:rwX data/ at the end of /etc/fstab? – 425nesp Aug 03 '14 at 21:07
  • @piña no. the only change you make to /etc/fstab is to change defaults to defaults,acl. setfacl is a command you should run from the terminal. data/ should be replaced by the path to the directory you want to change. – Segfault Aug 25 '14 at 16:07
34

Marking a directory setgid (g+s) will make new files inherit the group ownership of the directory, but the -g option of rsync will attempt to override this.

Ignacio Vazquez-Abrams
  • 112,653
  • 12
    The setgid bit only makes created files inherit the group /if/ the person creating the new file is a member of that group; if the creating user is the owner but not a member of the group, or the directory is world-writable, the setgid bit won't do anything. And the umask for all file-creating users still needs to be set to allow appropriate group access. – dannysauer Sep 12 '13 at 18:18
  • 1
    @dannysauer "if the creating user is the owner but not a member of the group ... the setgid bit won't do anything" - thank you. Makes sense now - but with no feedback from rsync, was wondering why it wasn't working. – user12345 Feb 05 '19 at 23:48
5

Other answers apply in a general case, but as you mention that rsync is a source of the problem, you may just need to tune its invocation.

For a start, the popular -a flag makes rsync copy permissions; use -r istead of -a or add -no-p (for no permission sync) and -no-g (for no group sync). Also rsync supports --chmod flag to alter permissions on newly created files.

mbq
  • 767
3

Your umask is wrong for the permissions you want. You want a umask of 002. You currently have a umask of 022. Also, the comment about making the directory setgid is correct, but I'm not sure if the file group ownership is something you want to change or not.

Unix file permissions are actually a very simple model. I find ACLs completely confusing myself. :-)

Omnifarious
  • 662
  • 5
    "Unix file permissions are actually a very simple model. I find ACLs completely confusing myself." - I kind of feel the opposite (but +1 anyways). ACLs (and Allow/Deny ACEs) are simple, and Unix permissions make no sense. But that's coming from a guy who is suffering a Postfix/Dovecot/Clam/SpamAssassin install. – jww Apr 02 '14 at 23:55