Talk:umask

Computing: Software / Free and open-source software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.
	This article is supported by Free and open-source software (assessed as Low-importance).

Null Heading

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I have several issues to present here:

It seems that Octal masks are NOT calculated, rather the resultant permissions are calculated.
Presenting the octal values, with the heading "allows (if specified)" may clear up the continued confusion regarding inverse, bitwise, and, unary, complement...
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.

The first digit of the umask ALLOWS setting read, write and execute of the user permissions which results in read and write (6) as requested.
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.
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)[reply]

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)[reply]

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)[reply]

This comment helped me finally understand umask. 16:38, 12 January 2012 (UTC) — Preceding unsigned comment added by Leafcat (talk • contribs)

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)[reply]

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)[reply]

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)[reply]

The definitions are clear but not obvious to the layman. The examples should remind the reader that the UMASK cmd 'sets the mask' which is opposite to the 'mode'. e.g 022 is 'taken away' from 777 resulting in 755. Preroll (talk) 10:23, 25 November 2013 (UTC)[reply]

security was not an issue* <-- This is patently untrue.

masking logic and truth table

Is this the proper place to really confuse people whit the n as material nonimplication or abjunction — Preceding unsigned comment added by DGerman (talk • contribs) 01:52, 18 January 2013 (UTC)[reply]

I made a few changes to that section, moving the more esoteric stuff toward the end. Sparkie82 (t•c) 01:42, 23 January 2013 (UTC)[reply]

Examples removed, why

Why were the demonstrative examples removed? DGerman (talk) 01:57, 18 January 2013 (UTC)[reply]

The article has more than a dozen examples. I don't see that any have been removed since the article was rewritten. Which edit or example are you referring to? Sparkie82 (t•c) 01:45, 23 January 2013 (UTC)[reply]

I refer to ( see version http://en.wikipedia.org/w/index.php?title=Umask&oldid=466169604

 $ umask 0022
 $ mkdir AnyoneCanListMyDir
 $ touch AnyoneCanReadMyFile.log
 $ ls -l
 drwxr-xr-x 2 dave develop 512 Aug 18 20:59 AnyoneCanListMyDir
 -rw-r--r-- 1 dave develop   0 Aug 18 20:59 AnyoneCanReadMyFile.log

Additionally the demonstrative Calculating resultant permissions example

This article now suffers, as is so often the case, in that it defines what the command does and gives examples of the command with the utmost attention to the finest details, but does not suggest "what good is this stuff?"

PS I'm not sure that after all the explanation regarding the mask bit creation/manipulation that the logic section clarifies anything.

I look forward to your follow up and defer some changes until then. DGerman (talk) 17:26, 22 February 2013 (UTC)[reply]

Mask effect

The sentence beginning 'If the mask has a bit set to "1", that means the corresponding file permission ...' can be simplified. The words "set to" are distracting. "Always" and "subsequently" are unnecessary. There is no reason to anticipate a mask applying selectively or retroactively. Also, the singular case suffices; no need for the plural. This sentence has the same meaning and is more easily understood. 'A "1" bit means the corresponding permission will be disabled when a file is created.' If no objection surfaces in a few weeks, I'll edit. Regards, ... PeterEasthope (talk) 15:44, 9 November 2013 (UTC)[reply]

umask and Pluggable Authentication Modules

PAM also has a bearing on the umask. Discussed in http://www.tldp.org/LDP/www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html for example. If someone can write a paragraph or two, that will help. Regards, ... PeterEasthope (talk) 16:35, 9 November 2013 (UTC)[reply]

rewrite coordinating with chmod command and File_permissions

Most of this article is duplicated in the chmod and the File_permissions articles. To prevent errors and increase the reader understanding of the inter-relationships of umask and chmod most of the umask article should be omitted. Additionally I don't think it is clear from the current umask article that umask does not actually change files or directories, rather it effects the modes assigned to files when they are created or when changes are attempted to file or directory permissions.

Awaiting feedback here.

DGerman (talk) 00:44, 16 July 2014 (UTC)[reply]

I'd like to collaborate in a rewrite of these articles. Besides what you mentioned, there could be improvements to the writing style, and either should the Modes_(Unix) article redirect to chmod, or there should be only limited info about modes in the chmod and it should link to Modes_(Unix) for further reading. Seeing as umask also introduces modes, probably the latter is best, and the same concise description of modes could be given in both places.

See also my Talk entry in chmod https://en.wikipedia.org/wiki/Talk:Chmod#Splitting_up_.27modes.27_table where I talk about some ideas to describe modes more clearly, especially the effect they have on files and directories.

Mwoc87 (talk) 19:49, 4 December 2014 (UTC)[reply]

Wrong Command Line Examples

The current version of the Article shows

`umask command issued`	How the mask is set after the command is issued
`(this entry has been removed) umask 777`	allow read, write, and execute permission for all (security risk) [Comment: do not even show this really bad idea DGerman]
`umask 000`	disallow read, write, and execute permission for all

but:

`umask command issued`	How the mask is set after the command is issued
`umask 777`	actually disallows read, write, and execute permission for all (e.g. 644 - 777 = 000)
`umask 000`	actually allows read, write, and execute permission for all (e.g. 644 - 000 = 644)

please correct me if I am wrong (I did not want to edit the article without confirmation because this made me unsure) — Preceding unsigned comment added by 95.89.159.155 (talk) 21:26, 26 July 2014 (UTC)[reply]

rework symbolic notation section

I have reworked the symbolic notation section. Sticking to the syntax and operations of the umask command. There was way too much explanation as to what the resulting file attributes meant. This is felt with extensively in BOTH the chmod article and file permissions.

Please don't include poor examples like setting file permissions so all users can write to the file. DGerman (talk) 23:16, 10 July 2015 (UTC)[reply]

Function call

It seems that including the function call information unnecessarily complicates this article. Very few people will be interested in this. I will remove it in the future unless someone STRONGLY objects. DGerman (talk) 23:21, 10 July 2015 (UTC)[reply]

Is "umask" really a concept in "computing"?

I quibble at the introductory "In computing, umask is". I think "umask" is a notion in UNIX, et al., operating systems, not a notion in computer science in general. Jmichael ll (talk) — Preceding undated comment added 03:57, 1 August 2014 (UTC)[reply]

Me too! Have rewritten it now, is it better or do you still have some suggestions?Mwoc87 (talk) 19:35, 4 December 2014 (UTC)[reply]

The purpose of using "In <some domain>" at the beginning of an article is to orient the reader. If some reader is looking for a type of halloween mask and comes upon this article, this will set them straight. Sparkie82 (t•c) 15:39, 24 January 2015 (UTC)[reply]

Right. But I believe that the prior comments indicate that it is not ubiquitous: computing - UNIX is not the empty set, so some qualification seems warranted. "In UNIX computing, ..." perhaps? 198.182.56.5 (talk) 20:57, 14 July 2016 (UTC)[reply]

History - some more information to clarify

umask was implemented in Version 7 UNIX, released in 1979. see umask(2).

The motivation came specifically from our PWB/UNIX work at Bell Labs Piscataway, whose efforts included creating the (likely) first real "UNIX computing center" where multiple systems provided support for large numbers of people from different departments and for years the largest such site. We were often early to encounter some kinds of security problems. Bell Labs Computing Research liked to run their systems in a fairly open fashion, with maximal permissions, with file creation 0666 wired in many programs. (That can be a problem, for example if one created a temp file writable by everyone, and somebody had a program that scanned for such things and opened for writing.) We wanted to run systems where defaults would be minimal permissions, set on system, group, or individual basis, but explicitly overridden as desired, and without changing code in numerous programs. Ken&Dennis were always minimalists, so I suggested this (some time in 1977/1978 when I was at Murray Hill) as a really simple way to cover the various ways people wanted to run systems. Most sysadmins could just add a umask call to system startup scripts.JohnMashey (talk) 23:05, 17 June 2017 (UTC)[reply]

truth table

Although purists use p and q with truth tables this seems unnecessary as the table explaining the actions is clearer. Strong objectors are welcome to undo my removal of that small section. DGerman (talk) 12:42, 3 April 2022 (UTC)[reply]

"umask -S" does not print the value of the umask

it prints the inverted value of the umask applied to 777, or, more formally, 777 AND NOT Umask. "umask --help" also gets that wrong. Heronils (talk) 06:49, 3 May 2024 (UTC)[reply]

For people having issues grasping the article

https://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work Heronils (talk) 06:50, 3 May 2024 (UTC)[reply]