5
$\begingroup$

The GNU manpage (what you'll find on a Linux system) – but pretty much any Unix manpage – of chown (the command for changing the owning user and owning group in Unix) appeal to an “owner” and, as you see, the very name of this command hints at “change owner”, too.

When people first learn this, they get the wrong idea, that for the command chmod (which sets the file/directory permissions), the abbreviation o (as in chmod o+w file) stands for “owner / owning user”.

In reality it stands for “other users”. So chmod o+w file really adds the writing permission (+w) for other users (who are not the owner or a member of the owning group). It doesn't help that what really refers to the “owner”, namely u (= owning user), makes it possible for one confusion to give rise to another: u is then confused for “‘normal’ users”: anybody not the owner or in the owning group.

Sure, it helps to make people directly aware of this, but even if they can remind themselves that there's some trap here, the idea o = “owner”, u = “normal users” is so seductive, that they retain some insecurity until enough (sometimes a lot is necessary) rote memorization makes it finally sink in.

What would be a mnemonic or other way to explain it which makes the correct notion stick right from the start, so rote memorization isn't necessary?

PS: I'm not formally teaching anyone, it's just what I want to tell coworkers/friends. When I took a university course on Linux I first came across this confusion. There's a lot more about the Unix permission system which is very counter-intuitive, but those are issues arising necessarily from technical aspects. Not an (surprisingly very) annoying and trivial issue caused by bad historical choices for abbreviations.

$\endgroup$
  • $\begingroup$ An interesting challenge. Let's see what folks come up with :) $\endgroup$ – Ben I. May 31 '18 at 5:30
  • $\begingroup$ Don't use shortcuts until you know what they mean. chmod 0760 <file> is quite explicit, and unambiguous. Once you know what's being done with that way, then, and only then, should you be willing to trust yourself to use chmod u+x,o-r <file>. $\endgroup$ – Gypsy Spellweaver May 31 '18 at 5:40
  • 2
    $\begingroup$ @GypsySpellweaver only that it is not a shortcut, but feature of the command that is EXTREMELY cumbersome to emulate using octal codes. $\endgroup$ – wolf-revo-cats May 31 '18 at 13:48
  • $\begingroup$ @GypsySpellweaver - but if all you want to do is change one permission bit (as the example shows with chmod o+w) there is no way to do that using what I call the "numeric method of stating permissions". I do test my students on them, mention that they most often appear that way in documentation, etc. I also teach them the u=rwx,g=rx,o= way of setting them which is equivalent to the numeric method. Some folks remember letters better - some folks remember numbers better. I do my best to teach all of the different ways. $\endgroup$ – ivanivan Jun 1 '18 at 1:22
  • $\begingroup$ Actually, the letter "x" means eXecute for files only. And "cross" for directories. So the whole thing is misleading. So, the better thing to do is to learn the exact meaning of the letters in the various contexts, instead of trying to guess. Same thing for the short options names of basic unix commands. $\endgroup$ – Michel Billaud Jun 1 '18 at 14:10
8
$\begingroup$

You could point out that a file has an owning user and an owning group. Since “owner” appears twice, specifying o for “owner” would be ambiguous. That's weak because the owning group doesn't really have any special privileges on the file, unlike the owning user: the owning user can change the file's permissions and other metadata, but the owning group only has the privileges granted by the file's permissions.

I think the best approach is to pair up user and group so that people remember them together. There's user and group: u and g. There are basic file permissions for one user and for one group. ACL entries can apply to either a user or a group. The command ls -l has two columns for ownership, one with the user and one with the group. Beware that sometimes the naming is not consistent. On the system there's a user database (/etc/passwd) and a group database (/etc/group). The chown command takes both a user and a group, but there's also a separate chgrp command and so chown is often used for the user only, which tends to reinforce the association between “user” and “owner”, so avoid mentioning that if you're trying to dispel the association between “user” and “owner”.

$\endgroup$
  • $\begingroup$ So in other words teach chown = change ownership? $\endgroup$ – Peter Taylor Jun 4 '18 at 10:56
3
$\begingroup$

Not an (surprisingly very) annoying and trivial issue caused by bad historical choices for abbreviations.

You say that u, g and o are bad historical choices for abbreviations, but that's just your take. u and g are linked to the uid and gid, the user and group id, which are used as identifiers throughout a unix system (Note that uid commonly refers to a user id, while the alternative you might propose, oid for owner id, often refers to an object id, so the original choice of uid over oid, or u over o, doesn't seem so bad to me)

My suggestion would be to talk about the Unix security model first (there are multiple users in a Unix system, each one is assigned a uid, once he's logged in every process he starts runs under his uid (don't mention suid etc in the beginning). You can add group memberships to this explanation.

Once you have a basic understanding of the security model, remembering what u, g and o stand for in the file permission mask becomes trivial.

In the meantime maybe it would help if you only ever talked about a user owning a file ("user" and the verb "owns", always together), but never of a file having an owner (note the absence of the word "user").

chown would then become "change who owns the file" instead of "change owner" (too bad the man page sabotages this).

$\endgroup$
  • $\begingroup$ I like this answer, though you sort of skirted past the confusion that wolf-revo-cats asked about, which is the somewhat odd mismatch between chown and chmod o.... Would you then say that chown should have been chusr? Or, more to the point, how would you get folks new to the unix model to avoid getting confused here in the first place? $\endgroup$ – Ben I. Jun 14 '18 at 12:18
  • $\begingroup$ Would you mind editing the answer itself to integrate your strategy for teaching about the mismatch? The comments down here are considered impermanent, and will eventually be wiped away. $\endgroup$ – Ben I. Jun 14 '18 at 20:45
  • $\begingroup$ Done. I'm fairly new here; do the comments get wiped automatically or is that done manually? $\endgroup$ – Pascal Jun 14 '18 at 20:52
  • $\begingroup$ It's normally done manually, but the central idea of SE is to create really high quality questions and answers that help future visitors. The comment tool is really just meant to provide an avenue to help improve questions or answers. The answer should still ultimately end up in the answer :) $\endgroup$ – Ben I. Jun 14 '18 at 20:58
0
$\begingroup$

UNIX has three rings of security they are

  • u, the user
  • g, the group
  • o, others (including Apache) on the same machine.

There are three levels of permission

  • r, read, which has octal value 4
  • w, write, which has octal value 2
  • x, execute, which has octal value 1

There are two ways to set permissions. One looks like this

chmod [ugo][+-][rwx] file(s)

Example

chmod ug-x

revokes execute permission from user and group.

More typically, you can do this

chmod abc file(s)

where a, b, and c are an octal digit. The digit a modifies user permissions, b group, and c others. Example

chmod 644 index.html

6 = 4 + 2, so user has read/write permissions 4 = 4 so group has read permissions 4 = 4 so others have read permissions

chmod 600 quiz.notYet

User has read/write Nobody else has any permissions.

To see permissions, use the ls -l command.

The chown command changes ownership. You can only do this to files you own. Root can do it to any file. Here are the two guises

chown username file(s)

chown username:groupname file(s)

The -R option will change ownership recursively within a directory.

$\endgroup$
  • 1
    $\begingroup$ This is a very clear explanation of the overall topic, but the question was about how to help students remember that the "owner" from chown does not refer to the o in chmod, but rather to the u. How would you do that? $\endgroup$ – Ben I. Jun 1 '18 at 14:19
  • $\begingroup$ Unix has the concept of file ownership. All files are owned by some user or they are owned by root. Owners then set permissions for their files as they see fit. All files in your home directory you create belong to you. $\endgroup$ – ncmathsadist Jun 1 '18 at 15:26
-1
$\begingroup$

UNIX has three rings of security ... There are three levels of permission ... and there's chown, chgrp, and chmod. That's all that anyone needs to remember, and all that anyone should ever be tested on. The rest is easily recovered via man chmod. I have been a professional developer on mostly Unix / Linux since 1978, and I still don't remember the full syntax of chmod arguments.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.