Sstrhsrtj

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?

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

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

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

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 forces you to log out

after login again

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