10

I've realized that the permissions for new files and directories behave a bit strangely. First of all, umask seems to return the right answer:

$ umask
0002

This means full access for my user and my group, no write access for the rest of the world, no suid. But if I create a file in my $HOME, this is how it looks:

$ ls -l testfile 
-rw-rw-rw- 1 robe robe 0 mar 16 12:58 testfile

i.e. , giving write access to everyone. The same happens with directories:

$ ls -ld testdir
drwxrwxrwx 2 robe robe 6 mar 16 13:00 testdir

I think this is the same as having umask 0000, not 0002. I've searched all /etc for some instance of umask that changes the default 0002 or 0022, but found none. This is a default CentOS 5.5 install. Any hint of why is this happening?

  • 3
    What filesystem type is your home directory on? – mattdm Mar 16 '11 at 12:33
  • 4
    And how are you creating testfile and testdir? – mattdm Mar 16 '11 at 12:34
  • 3
    @mattdm, you were right to insist: it's XFS. I forgot we have separate volumes for /home, /var and several more. Though I use XFS often and hadn't seen this behaviour. How can it be related? – rsuarez Mar 16 '11 at 14:13
  • 2
    acl can override umask locally. Is it possible your directories are being mounted with acl? – Faheem Mitha Mar 17 '11 at 21:33
  • 3
    Hmm, apparently xfs always has acl enabled. so it might not show in your /etc/fstab. Try running getfacl on your partitions/directories. – Faheem Mitha Mar 17 '11 at 21:40
3

I don't know if it's proper to answer my own question. Editors, please, advise on this if this is not the case. Thanks in advance.

I think I've solved this mystery: the problem was the lack of a default ACL on the XFS volumes. Here's the ACL entry for /srv/backups, one of the directories affected:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Whenever I did a "mkdir test" or "touch testfile", it would came up with permissions 777. So I did this:

setfacl -m d:u::rwx /srv/backups

Leaving the ACL like this:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

Previously there (supposedly) was no ACL, but now there is. I can see the "+" sign attached to the permissions when I do a "ls -l". And magically, now "mkdir test" and "touch testfile" work with the expected permissions:

# ls -l testfile 
-rw-r--r-- 1 root root 0 Dec 20 10:00 testfile
# ls -ld testdir
drwxr-xr-x+ 2 root root 6 Dec 20 10:00 testdir

I don't know why this happens. I guess XFS doesn't like not having a default ACL, and behaves strangely when it happens. Also, I've seen this happen only in CentOS, not in Debian/Ubuntu. Maybe it's related to the XFS version in the kernel, or something like that. No idea.

Anyway, that settles the case for me. Thanks a lot for all the suggestions :-)

0

The creat call can explictly specify permissions which take precedence over umask.

You haven't answered how you're creating testfile,testdir.

Create the file using touch testfile, then list and post the permissions

  • Sorry for the delay. I did test using "touch testfile", and also "mkdir testdir", with similar results. umask seems to be set to "0000", because they are created with permissions 777. – rsuarez Dec 20 '11 at 8:43
0

Try a getfacl . in the directory you are creating your test file, to see if there is a default acl affecting the permissions.

  • 1
    Nope, no default ACL. It seems to be related to XFS somehow, because it only happens in XFS volumes. But thanks anyway. – rsuarez Dec 20 '11 at 8:37
-1

Just look for the USERGROUPS_ENAB variable on /etc/login.defs

Them comment in order to disable it # USERGROUPS_ENAB yes

If you also want to change your current user's umask, you should first fallow the previous procedure and them do the following.

example for 027

echo "umask 027" >> ~/.bashrc && pkill -KILL -u your_username_here

echo "umask 027" >> ~/.bashrc this command will set an umask default value for your profile

this will force you to log out

after login again

just run the umask comand again and see if it works for you

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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