umask setting changes after cd [closed]

Question

I've got something odd to report. On my newly configured RHEL5 server my shell is set to /bin/bash I have umask set to 002 in .bashrc.

When I first log in, umask appears to work correctly:

$ touch a
$ ls -l a
-rw-rw-r-- etc.....

if I create another file it works:

$ touch b
$ ls -l b
-rw-rw-r-- etc.....

but... if I change directory (to any directory), then umask gets set back 022:

$ cd /var/www/whatever
$ touch c
$ ls -l c
-rw-r--r-- etc.....

completely bizarre.

Anybody seen anything like this? Can they think of anything to check?

why would the umask setting change after cd'ing?

Thanks,

-Charlie

Answer 1

Thanks to Barry Brown for the comment above - I was tearing my hair out with this problem (on OSX, not Linux) and it is indeed rvm that was the culprit in my case. Check your .profile, .bash_profile etc for a line like this:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

Comment it out, relaunch your shell and that should solve the problem. I had no idea rvm was so rude and intrusive. Better to load it only when needed rather than for every shell.

Answer 2

The short answer is: the umask has four digits and it does not change arbitrarily, but /etc/profile and fiends will set it to 022 by default;

update
I kinda got carried away with this and forgot to properly answer your question:

Check that the partition (if any) mounted on the folder where you change to, does not have a umask set. (just type mount)

The long answer is:

man chmod §6: A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros. The first digit selects the set user ID (4) and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file's group, with the same values; and the fourth for other users not in the file's group, with the same values.

GNU coreutils 8.14 October 2011

---

I remember reading this man page several times some years back, and never quite understanding what all of this means before I set up a table. Since I've lost my reference table, I'll recreate it here. Since I don't like the symbolic notation becasue it is more cumbersome to type (e.g chmod u+x), I'll leave out any mention of it.

---

Interpretation of chmod and umask

Possible setting: 4: read 2: write 1: execute

Possible values of each digit with examples

domain  setuid  user    group   world
digit   1       2       3       4
values  0-7     0-7     0-7     0-7

The `possible setting' values in the curly braces {} may be summed together to produce a valid permission bit (number).

Common examples

0755: The user may enter a folder and write (remove) files in that folder If this mask is set on a file, the the user may execute the file (i.e. ./filenme.bin). The last two digits mean that the group to which the file belongs and the world (anyone else on the system), may execute the file as well. Applied to direcotories it means that the group and world may enter that directory.

0644: User may read and write a file, but not execute it. Group and world may only read the file. Applied to a folder, this mask wil prevent anyone from entering that directory.

0600: Only the owner may read and write a file with this mask

0700: Only the owner of a folder may enter, read and write the contents of a folder with this mask.

0000: Useful for "hiding" files or for signaling (to yourself) that a file or a folder is not supposed to be used.

Meaningless masks

0200: If a user can write a file, then they may also alter the umask of a file.

Dangerous masks

0666: Everyone can read, write to and delete a file with this mask

0777: Same thing for a folder. If a binary file is set 777, then anyone can put anything they want into that file and run it, even if it is in the system- wide binaries directory such as /usr/bin.

4755: Binary files owned by the superuser (root) will run with superuser permissions. The implications of this should be clear. Perhaps, counder- intuitively setting an interpreted-script with 4755 will have no effect becasue a script (such as a bash script) is still run by /bin/bash. The text file where the script is stored is not really an executable.

In all of the above examples, the leading zero may be omitted for convenience.

Converting umask to chmod

To set a proper umask, all that needs to be done is subtracting the unwanted permissions from the `maximum mask' which by is 0777 for folders and 666 for files.

To force the shell to create files with the default permission of 644 set umask to 0022. For folders, the typical (desired) umask might be 755 and is acheived by setting the umask to 0022.

 0666  0777
-0022 -0022
 ____  ____
 0644  0755

---

Relative links: https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts