andy@syma.sussex.ac.uk (Andy Clews) (08/31/90)
I'm writing a guide to UN*X for our Computing Service, and the ugly
subject of umask has surfaced. Our system is DYNIX 3.0.17 (based mostly
on 4.2BSD) and the umask is the old-style one wherein you have to
specify default protection codes as a 1's complement number. Not only
does this scare the hell out of novices, it is also giving me a sore
brain trying to work out the simplest way of explaining how to use it.
Has anyone out there ever succeeded in explaining the old umask to
novices and had them go away happy? If so, I would be eternally grateful
if you would be willing to share your wisdom with me. I'll even give
donors an acknowledgement in my guide ("big deal" I hear you cry :-)
Marks will be awarded for conciseness and the less buzzwords and
computerese the better!
Please note: only the "umask 022" style is acceptable. Those lucky
people with the "umask u=rw" version can go and be smug elsewhere! ;-)
Feel free to email me. I will probably summarise if any umaskophobes out
there would like to benefit from this discussion.
Thanks for listening.
--
Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England
JANET: andy@syma.sussex.ac.uk BITNET: andy%syma.sussex.ac.uk@uk.acdhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (09/02/90)
Here's a good explanation:
You are already provided with a file protection default, which
allows everybody to read your files, but only allows you to change
them. All files you created are created such that only you can
change them. (However, your default mailbox directory called Mail
is protected so that nobody else can read or change anything in
it.)
If you do not with others to be able to read any of your files,
look for a line saying "umask 022" in the file {.login,.profile}
in your home directory and change it to:
umask 066
Once you have made this change and logged in again, all files you
create will be readable and changeable only by you.
Other values of umask are possible; however, we recommend you not
attempt to use them until you have fully understood the meanings
of these values. For further information, see the following
online manuals: chmod(1), chmod(2), and umask(2).
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesichris@mimsy.umd.edu (Chris Torek) (09/02/90)
In article <3373@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: >I'm writing a guide to UN*X for our Computing Service .... You too, eh? :-) (Except here it is for new grad students and professors.) >the subject of umask has surfaced. Well, time to give this one a go, I guess. 1. Permissions: Unix files have three basic permissions, `read', `write', and `execute' (sometimes abbreviated to `rwx'). These let you read a file, write a file, and run it as a command. There is no `remove a file' permission, so there must be some other way to handle that. 2. Therefore, directories get the same three basic permissions. Reading a directory means `looking at the names of the files in that directory'. Writing a directory means `changing the names, adding new names, or removing names.' These are obvious and reasonable, but there is one left, and it is not obvious and simply must be memorized: `Executing' a directory really means `using the directory'. Without execute permission, you cannot do anything to or with any of the names in the directory. You may still be able to look at the names, but that is all. 3. These three permissions let you decide what you can do to your own files, but there are other users on the system. Thus, the same three permissions may be applied to other people as well. For convenience, `other people' are divided into two classes: those who divide people into classes, and those who do not. Oops, sorry, a little joke there. Other people are divided into `people in your groups' and `everyone else'. You can find out which groups you are in by running the `groups' command. You can label any file you own as belonging to any one of those groups, and then you can grant other people who belong to that particular group any of the same permissions you can give yourself: read, write, and execute. Everyone else---those who are neither yourself, nor in the group you attached to your file---go through a third set of permissions. 4. To change the group label on a file or directory, use the `chgrp' command. (Newly created files get the same group as the directory they are in, except sometimes under SunOS 4.x and System V Release 4; we will ignore these systems.) 5. To change the permissions on an existing file, use the `chmod' command. For instance, to make you, the User, be able to read and execute a file, to make its Group able to execute it only, and to make all Others have no access at all, you would use `chmod u=rx,g=x,o= myfile'. 6. These permissions are actually kept as three groups of three, in the order `user, group, other'. Each group of three can be written as a single digit: read=4, write=2, execute=1; add them together to allow more than one thing. Write 0 for `none'. The permissions above, `u=rx,g=x,o=', can be written as 4+1,1,0 or `510'. Thus you could also say `chmod 510 myfile'. Fortunately, the chmod command lets you use the names instead of the numbers. [finally, a page or two down, we get to `umask'] 7. What about new files? What permissions do they get? Every program that *creates* a new file knows what it is good for: whether it should be written, or executed; whether it should be private (because it is personal mail); and so forth. Thus, each program that creates a file or directory gives it as much permission as it possibly can. When you use the C compiler, for instance, it makes new programs executable by everyone. When you edit a new text file, the editor makes it readable and writable by everyone, but executable by no one---your prose would probably not be understood by a dumb computer anyway. Chances are, though, that you do not want to let *everyone* edit your files, remove your programs, and so forth. You probably do not even want people in your group to change things. You might even not want anyone else to read or execute what you wrote. Unix systems therefore provide something called a `umask'. The umask is the set of permissions you want to *take away*. The umask you get when you log in *takes away* write permission for people in your group and for others: it *takes away* `u=,g=w,o=w' in chmod's terms. If you wanted to take away all permissions for people outside your group, you could set it to `u=,g=w,o=rwx'. The command you use to change your umask is called `umask'. You might think, then, that you could type `umask u=,g=w,o=rwx'. Unfortunately, the umask command is not as smart as the chmod command. It only takes the numbers. Again, the numbers are Read=4, Write=2, eXecute=1, and the order is User, Group, Other. So instead of `u=,g=w,o=rwx' you have to use 0, 2, and 4+2+1. To make your umask *take away* g=w and o=rwx, then, you have to type `umask 027'. Your default umask *takes away* g=w and o=w, so it is `022'. If you do not want to take away g=w, you would want `002'. If you wanted to take away g=rwx and o=rwx, you would want `077'. If for some reason you did not even trust yourself, you could take away everything with u=rwx,g=rwx,o=rwx: `777'. 8. Remember, your umask only *takes away* permissions granted by programs, and only affects new files and directories. You must use `chmod' to *add* permissions or to change existing files and directories. This may seem rather roundabout, but is actually the best way to do things. If you had a command to add permissions to newly created files, you would have to change the permissions every time you switched from making new text files to new commands. If you normally allowed your group or others to read your text files, you would have to change your permissions every time you worked on private mail files. If you forgot, you would have to run `chmod' quickly to take away the extra permissions---and this would leave a `time window' when someone could read your mail. As it is, you only have to use chmod to *add* permissions, and at most this will delay someone else who is expecting to read or execute your file. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris