UMASK: need help explaining it

[Chris Torek]

In article <3373 at syma.sussex.ac.uk> andy at 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 at cs.umd.edu	Path:	uunet!mimsy!chris