Talk:Umask

Serious attempt to clean up and correct some of the confusion which in fact lead me to previously present a table of ALLOWED permissions which someone rewrote, correctly, since they are actually removed permissions. Hope no one is offended by my removing that really nasty binary calculation. DG12 (talk) 03:40, 20 August 2011 (UTC)

This doesn't look like a bitwise AND to me; more like a subtraction. 777 & 177 makes 177, not 600, wherease 777-177 does make 600. The unix man pages for umask(1) also refer to subtraction rather than ANDing.

That sounds right to me. With my umask set to 002, if I create a new file or directory it has its permissions set to 0775, which of course is 777-002. On the other hand, the man page for the C function (umask(2)) that I have says "umask sets the umask to mask & 0777." I don't know enough on this subject to make an edit, though. Does anyone have an idea of how that bit should be written? It's somewhat confusing as it is. --Dirk Gently 03:48, 28 July 2005 (UTC)

Doesn't the current notation (^ ~) indicate the XOR of the complement of the argument? I think that's incorrect, and at least, could be simplified greatly to say simply the complement, (~) of the argument (although it should probably be explicitly stated as such for clarity). It comes out like the following:

~177₈ = 600₈

--Max Magee

This is correct. ^ = XOR. I'm the editor who did those major changes back in 17 August 2005. Note it was a simple AND before, and totally wrong. The XOR with the argument itself (not with the complement!) also works. Prove me wrong. A ^ B in this case will give the same result as in A AND ( ~ B). -andy 80.129.114.15 04:05, 14 January 2007 (UTC)

666 AND NOT 174 = 602 = eh?

It is correct that 666 AND NOT 174 = 602. It is also NOT true in general that A ^ B = A AND ~B. In fact, an XOR can be reduced to (A AND NOT B) OR (B AND NOT A). Using the standard notation for boolean algebra ( + for OR and . for AND) we can define the XOR by the following:

   A^B = (A+B)(~(AB))
   and reduction gives:
   = A(~AB) + B(~AB)
   = A(~A + ~B) + B(~A + ~B)
   = ~AA + ~BA + ~AB + ~BB
   = ~BA + ~AB

Using ~ instead of a bar necesitates that it has a higher precedent than '.' or '+' . John Pearcey 83.147.135.251 10:16, 9 April 2007 (UTC)

Yes, yes. All correct. BUT in the umask case, the XOR 777₈ variant does work, so I see no reason in removing it. (It has been removed again, though.) -andy 92.227.16.69 (talk) 03:30, 17 July 2008 (UTC)

---

I have several issues to present here:

1. It seems that Octal masks are NOT calculated, rather the resultant permissions are calculated.
2. Presenting the octal values, with the heading "allows (if specified)" may clear up the continued confusion regarding inverse, bitwise, and, unary, complement...
3. In these days of more evil individuals is it a better idea to recommend using 027 or 007 instead of the traditional 022 or 002 ?

Is this correct?

"Octal umasks are calculated via the bitwise AND of the unary complement of the argument (using bitwise NOT) and the permissions specified by the program:"

or does the following resolve the first 2 issues I presented?

Octal umasks (the usual leading 0 to indicate octal is not used ):

Octal	ALLOWS(if requested)	bit mask
0	read, write and execute	111
1	read and write	110
2	read and execute	101
3	read only	100
4	write and execute	011
5	write only	010
6	execute only	001
7	no permissions	000

Resultant permissions are calculated as the AND of the bit mask and the permissions requested by the program.

The most common default case is a program creating a file requests permissions 666 ( read and write for user, group and other) and a umask of 022 allowing only read and execute.

1. The first digit of the umask ALLOWS setting read, write and execute of the user permissions which results in read and execute (6) as requested.
2. The second digit of the umask ALLOWS ONLY setting read and execute of the group permissions which results in read (4) as write is not allowed.
3. the third digit of the umask ALLOWS ONLY setting read and execute of the other permissions which results in read (4) as write is not allowed.

The resultant file permissions are RW-R--R--. This may not be the best in an environment of malicious users. Perhaps a better value for umask would be 027 not allowing and access to others. Another common value is 002, which leaves the write permission for the file's group enabled. This can be used for files in shared workspaces, where several users work with the same files.

DG12 (talk) 16:38, 6 March 2011 (UTC)

Clarity

This article seems to be a little hazy and unclear to me. What exactly is umask? From what I can understand, it's 'default permissions'. In other words, a way of automatically setting chmod permissions, so if umask is 777 for my application, all files created from my application will have 777 as the default chmod values. Is this right? The article doesn't exactly make that clear Grayda 00:35, 16 November 2007 (UTC)

Not quite. You've got the idea right but the calculations wrong. Putting aside the binary logic and focusing just on numerical permissions, you have an octal number to which you add your permissions, effectively making a bitfield. For permissions, 4 means read, 2 means write, and 1 means execute. Add these together to get one permission value. For example, having read and write access would give you 6, or having just read and execute access would give you 5. Place three of these values together to get the numerical permissions, and prefix it with a 0 to explicitly specify that you're using an octal number. The permission set giving the owner r/w/x, the group r/w, and others x, would be 0761.

Now to actually answer your question. The umask is really what rights not to grant. If your umask is set to 0100, the permissions on created files will be 0677. Similarly, using a umask of 0133 will make the permissions on created files 0644. Hope this helps! Dandaman32 (talk) 03:41, 21 November 2007 (UTC)

This comment helped me finally understand umask. 16:38, 12 January 2012 (UTC)

• OK, so now can we get the article to have some examples that are clearer to our target audience? I.e. more task-oriented and less mathematical? --Treekids (talk) 21:41, 14 February 2008 (UTC)

The first sentence of the article says that the file mode creation mask is set by the umask. The second says the file mode creation mask is the umask. Which is it--one or the other, or both? —Preceding unsigned comment added by 64.244.192.146 (talk) 14:11, 3 November 2010 (UTC)

Umask is a system call, a shell builtin command that calls it, and the colloquial term for the file creation mask. Sorry for the confusion, and in retrospect it would likely have been easier to understand if expressed as mode AND umask, rather than mode AND NOT umask. I don't recall why we did it that way. JohnMashey (talk) 07:48, 2 February 2011 (UTC)