why newly created file permission always 644...umask issue

eboy98 · 03-05-2010, 08:41 PM

Hello There,

i have some confusion about umask.What i have learned by this time.... with umaks value i can control the permission of new files. Like if i set umaks value to 077 for an user then that users newly created file permission would be (777-077) = 700.

I use /etc/bashrc file

Code:

# Even for non-interactive, non-login shells.
if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 077
else
    umask 022
fi

In this file i have changed the red color umask value.Now i su to john try to create new file

Code:

[john@pc5 ~]$ touch file
[john@pc5 ~]$ ll
total 1
-rw-r--r--+ 1 john john 0 Mar  5 21:36 file
[john@pc5 ~]$ umask
0077

Here new file create with permission value is 644 ?

I don't get it.How can I make this work?

Thank You.

win32sux · 03-05-2010, 11:30 PM

Quote:

Originally Posted by eboy98

Like if i set umaks value to 077 for an user then that users newly created file permission would be (777-077) = 700.

For files (instead of directories), subtract the umask from 666, not 777. For example, a umask of 022 would mean files of 644 (666-022) and directories of 755 (777-022). The 077 umask you're using results in 589 for files, which is an invalid mode. I'm willing to bet that if you create a directory it'll be set to 700, though.

spacewrench · 03-06-2010, 09:14 PM

That's weird, it works for me (Ubuntu 9.something, bash).

Here's me testing several different umasks:

Code:

dhm@voodoo$ umask
0002
dhm@voodoo$ touch x
dhm@voodoo$ ls -l x
-rw-rw-r-- 1 dhm mersenne 0 2010-03-06 19:07 x
dhm@voodoo$ umask 022
dhm@voodoo$ umask
0022
dhm@voodoo$ touch y
dhm@voodoo$ ls -l y
-rw-r--r-- 1 dhm mersenne 0 2010-03-06 19:07 y
dhm@voodoo$ umask 077
dhm@voodoo$ umask
0077
dhm@voodoo$ touch z
dhm@voodoo$ ls -l
total 0
-rw-rw-r-- 1 dhm mersenne 0 2010-03-06 19:07 x
-rw-r--r-- 1 dhm mersenne 0 2010-03-06 19:07 y
-rw------- 1 dhm mersenne 0 2010-03-06 19:07 z

Incidentally, you don't do the calculation by subtracting, it's by logical NOT-AND. Also, the program that creates the file or directory specifies a protection, which is then NANDed with the process' umask (if I'm remembering everything correctly). So the touch program probably specifies a protection of 0666 (rw-rw-rw) and some bits of that are usually turned off by the umask. Mkdir, on the other hand, probably specifies a protection of 0777 (rwxrwxrwx) and some of those bits are turned off by the umask. A program such as a linker that is creating an executable file will probably specify a default protection of 0777, so that the file will have the X bit set.

HTH

eboy98 · 03-06-2010, 11:34 PM

Quote:

Originally Posted by spacewrench

That's weird, it works for me (Ubuntu 9.something, bash).

HTH

Thanks for for you answer,I know this can be done by using umask command.
but a as a root if i want to set a default umask value for one of my user then how should i proceed.... Is it even possible?

win32sux · 03-07-2010, 12:03 AM

eboy98, why don't you (as a test) just set the umask in your conditional to something like 026 instead of 077 and then check whether user john's files get created by touch as 640 (666-026) and his directories by mkdir as 751 (777-026).

If they do, then you know your current approach already works.

jschiwal · 03-07-2010, 12:25 AM

When a new file is created it is created with 666 permissions. The umask value is then ANDed with these permissions to determine what the permissions will be set to.

In your scripts, always precede the mask values with 0 because they are octal numbers.
Inside $((..)) or [[ .. ]], an expression may be interpreted as an integer. If you use 177 instead of 0177, it might not be what you think.

> um=$((0177))
> echo $um
127

> um=$((177))
> printf "%o\n" $um
261

chrism01 · 03-07-2010, 07:55 PM

You could use the symbolic notation instead; it sets what you ask for

Quote:

If a symbolic mask is specified, the actual file permission bits, and not the inverse, should be specified.

http://linux.die.net/man/1/umask

eboy98 · 03-09-2010, 03:12 AM

Quote:

Originally Posted by win32sux

eboy98, why don't you (as a test) just set the umask in your conditional to something like 026 instead of 077 and then check whether user john's files get created by touch as 640 (666-026) and his directories by mkdir as 751 (777-026).

If they do, then you know your current approach already works.

I dont know what happened...but now every thing works fine....i can change user umask value from /etc/bashrc file....i dont understand what happened earlier....

I am using rhel5 at VirtualBox.

Code:

[john@pc5 ~]$ umask
0026
[john@pc5 ~]$ touch file
[john@pc5 ~]$ ll
total 4
-rw-r----- 1 john john 0 Mar  6 10:58 file
[john@pc5 ~]$ mkdir testDir
[john@pc5 ~]$ ll
total 12
-rw-r----- 1 john john    0 Mar  6 10:58 file
drwxr-x--x 2 john john 4096 Mar  6 10:58 testDir
[john@pc5 ~]$

win32sux · 03-09-2010, 03:20 AM

Quote:

Originally Posted by eboy98

I dont know what happened...but now every thing works fine....i can change user umask value from /etc/bashrc file....i dont understand what happened earlier....

I am using rhel5 at VirtualBox.

Code:

[john@pc5 ~]$ umask
0026
[john@pc5 ~]$ touch file
[john@pc5 ~]$ ll
total 4
-rw-r----- 1 john john 0 Mar  6 10:58 file
[john@pc5 ~]$ mkdir testDir
[john@pc5 ~]$ ll
total 12
-rw-r----- 1 john john    0 Mar  6 10:58 file
drwxr-x--x 2 john john 4096 Mar  6 10:58 testDir
[john@pc5 ~]$

Yeah, that pretty much confirms your script is working properly.

What do you get if you run that same exact test with the 077 umask value?

eboy98 · 03-10-2010, 02:38 AM

Quote:

Originally Posted by win32sux

Yeah, that pretty much confirms your script is working properly.

What do you get if you run that same exact test with the 077 umask value?

Yes it also changed.....that you were expecting,mentioned at the earlier post.

Here is the output:

Code:

[john@pc5 ~]$ umask
0077
[john@pc5 ~]$ touch file
[john@pc5 ~]$ mkdir testDir
[john@pc5 ~]$ ll
total 12
-rw------- 1 john john    0 Mar  6 12:42 file
drwx------ 2 john john 4096 Mar  6 12:42 testDir
[john@pc5 ~]$

win32sux · 03-10-2010, 03:38 AM

Quote:

Originally Posted by eboy98

Yes it also changed.....that you were expecting,mentioned at the earlier post.

Here is the output:

Code:

[john@pc5 ~]$ umask
0077
[john@pc5 ~]$ touch file
[john@pc5 ~]$ mkdir testDir
[john@pc5 ~]$ ll
total 12
-rw------- 1 john john    0 Mar  6 12:42 file
drwx------ 2 john john 4096 Mar  6 12:42 testDir
[john@pc5 ~]$

Okay, so the directory gets set to 700 (as expected), but the file gets set to 600. This matches the behavior which spacewrench observed when using the 077 umask value. So it still looks (to me, at least) like 589, being an invalid mode, triggers the use of a fallback mode (which would explain why the other umask value you tried works just fine). Could anyone confirm whether that is indeed what is happening? If so, where is the fallback mode obtained from?

jschiwal · 03-13-2010, 04:27 AM

If you enter "umask 589", the argument is rejected and the umask isn't changed. The argument must be an octal number and be a legal value.
I just use bash, and umask is a shell builtin function.

win32sux · 03-13-2010, 04:37 AM

Quote:

Originally Posted by jschiwal

If you enter "umask 589", the argument is rejected and the umask isn't changed.

Wait, I'm not sure I'm following you — why'd you try 589 as a umask value?

jschiwal · 03-13-2010, 04:50 AM

I wouldn't.

Quote:

So it still looks (to me, at least) like 589, being an invalid mode, triggers the use of a fallback mode.

win32sux · 03-13-2010, 04:57 AM

What I was referring to in that quote was that 589 would be the resulting file permission mode for a 077 umask value. Since we know a file can't have 589 permissions, a different mode for files is being used when a umask 077 value is specified. Based on the above posts, that mode is 600, but how (or from where) is that value automatically computed (or selected)?