11

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?

tshepang
  • 64,472
  • 86
  • 223
  • 290
rsuarez
  • 902
  • 1
  • 7
  • 24
  • Try log out and in again, and see if the problem persists. Try first on one of the Virtual terminals (Ctrl+F1), if you are on a Desktop (I don't want you losing your desktop session for nothing). – tshepang Mar 16 '11 at 12:17
  • 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
  • Did you try to set umask with different values and then using mkdir and touch? – varrtto Mar 16 '11 at 13:15
  • @Tshepang, I'm using ssh. It's a virtual machine hosted in Gandi. – rsuarez Mar 16 '11 at 13:45
  • @mattdm, it's ext3. – rsuarez Mar 16 '11 at 13:45
  • (ok, trying not to hit "enter" before answering everyone this time :-)) @mattdm and @user5774: I used mkdir and touch to create the directory and file, and tried changing my umask to 022 and 077. No change: files and directories still had the same permissions. Thanks! – rsuarez Mar 16 '11 at 13:48
  • @rsuarez — are you absolutely sure it's ext3? I apologize for being annoying on this point, but it does seem like a top possibility to rule out. – mattdm Mar 16 '11 at 13:48
  • @rsuarez: Actually, one can't reply to more than person at a time, so you are doing it right (http://meta.stackexchange.com/q/43019/147166). – tshepang Mar 16 '11 at 13:49
  • @rsuarez: Maybe stop the ssh session and restart it. I am assuming that this achieves what logging in and out does. – tshepang Mar 16 '11 at 13:50
  • 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
  • Can you `chmod` it to the correct permissions? – stribika Mar 16 '11 at 19:02
  • @stribika, yes, I can chmod it to the correct permissions. But obviously, I'd rather not have to do it every time :-) – rsuarez Mar 17 '11 at 14:08
  • 2
    acl can override umask locally. Is it possible your directories are being mounted with acl? – Faheem Mitha Mar 17 '11 at 21:33
  • If acl is enabled, it is probably being enabled in /etc/fstab. – Faheem Mitha Mar 17 '11 at 21:36
  • 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
  • @Fatheem, thanks for the input, but acl shouldn't be a problem (I guess). getfacl doesn't show anything strange: no default permissions, just the same that chmod shows (user rwx, group r-x, other r-x). Also, there is no entry with extended attributes (the usual "+" sign in a "ls -l"). Any other idea? – rsuarez Mar 23 '11 at 09:13
  • Did you do 'ls -ld .' and there was no + in the permissions. As it is the permission of the directory that matters. Sorry to state the obvius but ... (my guesses where umask, acl, file-system. The chmod experiment ruled out file-system, you initially ruled out umask.) – ctrl-alt-delor Mar 23 '11 at 16:31
  • @Richard, yes, there's no "+" in the permissions. I'm totally lost about what's happening here, though obviously it's related to how CentOS behaves with XFS. – rsuarez Mar 29 '11 at 08:01
  • Did you try `strace -f touch test.dat` yet? Perhaps you can see there what is going wrong... – Nils Nov 26 '11 at 21:34
  • what are the mount options for the filesystem? perhaps, that can show some light. – Nikhil Mulley Dec 06 '11 at 15:28
  • Try a `getfacl .` in the directory you are creating your test file, to see if there is a default acl affecting the permissions. – Andrew Dec 12 '11 at 11:34
  • 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 08:37

3 Answers3

4

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 :-)

rsuarez
  • 902
  • 1
  • 7
  • 24
  • Answering your own question is [perfectly acceptable](http://meta.stackexchange.com/questions/17463/can-i-answer-my-own-questions-even-those-where-i-knew-the-answer-before-asking). – Keith Thompson Dec 20 '11 at 10:30
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

bsd
  • 10,916
  • 4
  • 30
  • 38
  • 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 08:43
-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

user336810
  • 1