Answers.Body: <p>UNIX has three rings of security they are</p>
  
  <ul>
  <li>u,  the user</li>
  <li>g, the group</li>
  <li>o, others (including Apache) on the same machine.</li>
  </ul>
  
  <p>There are three levels of permission</p>
  
  <ul>
  <li>r, read, which has octal value 4</li>
  <li>w, write, which has octal value 2</li>
  <li>x, execute, which has octal value 1</li>
  </ul>
  
  <p>There are two ways to set permissions. One looks like this</p>
  
  <p><code>chmod [ugo][+-][rwx] file(s)</code></p>
  
  <p>Example </p>
  
  <p><code>chmod ug-x</code></p>
  
  <p>revokes execute permission from user and group.</p>
  
  <p>More typically, you can do this</p>
  
  <p><code>chmod abc file(s)</code></p>
  
  <p>where a, b, and c are an octal digit. The digit a modifies 
  user permissions, b group, and c others. Example</p>
  
  <p><code>chmod 644 index.html</code></p>
  
  <p>6 = 4 + 2, so user has read/write permissions
  4 = 4      so group has read permissions
  4 = 4      so others have read permissions</p>
  
  <p><code>chmod 600 quiz.notYet</code></p>
  
  <p>User has read/write
  Nobody else has any permissions.</p>
  
  <p>To see permissions, use the <code>ls -l</code> command.</p>
  
  <p>The <code>chown</code> command changes ownership. You can only do this to files
  you own.  Root can do it to any file.  Here are the two guises</p>
  
  <p><code>chown username file(s)</code></p>
  
  <p><code>chown username:groupname file(s)</code></p>
  
  <p>The <code>-R</code> option will change ownership recursively within a directory.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-01T14:19:08.970Z
Answers.Text: 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?
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-01T15:26:15.293Z
Answers.Text: 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.
Answers.UserDisplayName: ncmathsadist
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-01T12:29:02.780Z
Answers.LastActivityDate: 2018-06-01T12:29:02.780Z
Answers.UserDisplayName: ncmathsadist
Answers.Body: <p>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 <code>man chmod</code>.  I have been a professional developer on mostly Unix / Linux since 1978, and I still don't remember the full syntax of chmod arguments.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-20T01:35:36.947Z
Answers.LastActivityDate: 2018-06-20T01:35:36.947Z
Answers.UserDisplayName: kevin cline
Answers.Body: <p>You could point out that a file has an <em>owning user</em> and an <em>owning group</em>. Since “owner” appears twice, specifying <code>o</code> 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.</p>
  
  <p>I think the best approach is to pair up <em>user</em> and <em>group</em> so that people remember them together. There's <strong>u</strong>ser and <strong>g</strong>roup: <code>u</code> and <code>g</code>. 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 <code>ls -l</code> 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 (<code>/etc/passwd</code>) and a group database (<code>/etc/group</code>). The <code>chown</code> command takes both a user and a group, but there's also a separate <code>chgrp</code> command and so <code>chown</code> 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”.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-04T10:56:40.827Z
Answers.Text: So in other words teach **chown = change owner*ship***?
Answers.UserDisplayName: Peter Taylor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-31T07:00:06.810Z
Answers.LastActivityDate: 2018-05-31T07:00:06.810Z
Answers.UserDisplayName: Gilles 'SO- stop being evil'
Answers.Body: <blockquote>
    <p>Not an (surprisingly very) annoying and trivial issue caused by bad historical choices for abbreviations.</p>
  </blockquote>
  
  <p>You say that <code>u</code>, <code>g</code> and <code>o</code> are bad historical choices for abbreviations, but that's just your take. <code>u</code> and <code>g</code> are linked to the <code>uid</code> and <code>gid</code>, the <strong>user</strong> and <strong>group id</strong>, which are used as identifiers throughout a unix system (Note that <code>uid</code> commonly refers to a <em>user id</em>, while the alternative you might propose, <code>oid</code> for <em>owner id</em>, often refers to an <em>object id</em>, so the original choice of <code>uid</code> over <code>oid</code>, or <code>u</code> over <code>o</code>, doesn't seem so bad to me)</p>
  
  <p>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 <code>uid</code>, once he's logged in every process he starts runs under his <code>uid</code> (don't mention <code>suid</code> etc in the beginning). You can add group memberships to this explanation.</p>
  
  <p>Once you have a basic understanding of the security model, remembering what <code>u</code>, <code>g</code> and <code>o</code> stand for in the file permission mask becomes trivial.</p>
  
  <p>In the meantime maybe it would help if you only ever talked about a <em>user owning</em> a file ("user" and the verb "owns", always together), but never of a file having an owner (note the absence of the word "user").</p>
  
  <p><code>chown</code> would then become "change who owns the file" instead of "change owner" (too bad the man page sabotages this).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T12:18:20.580Z
Answers.Text: 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?
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T20:45:05.517Z
Answers.Text: 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.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T20:52:14.427Z
Answers.Text: Done. I'm fairly new here; do the comments get wiped automatically or is that done manually?
Answers.UserDisplayName: Pascal
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T20:58:55.730Z
Answers.Text: 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 :)
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-12T11:53:22.877Z
Answers.LastActivityDate: 2018-06-14T21:01:49.557Z
Answers.LastEditDate: 2018-06-14T21:01:49.557Z
Answers.UserDisplayName: Pascal
Body: <p>The GNU manpage (what you'll find on a Linux system) – but pretty much any Unix manpage – of <code>chown</code> (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  “<strong>ch</strong>ange <strong>own</strong>er”, too.</p>
  
  <p>When people first learn this, they get the wrong idea, that for the command <code>chmod</code> (which sets the file/directory permissions), the abbreviation <code>o</code> (as in <code>chmod o+w file</code>) stands for “owner / owning user”. </p>
  
  <p>In reality it stands for “<strong>other</strong> users”. So <code>chmod o+w file</code> really adds the writing permission (<code>+w</code>) for <em>other</em> users (who are not the owner or a member of the owning group). It doesn't help that what <em>really</em> refers to the “owner”, namely <code>u</code> (= owning <strong>u</strong>ser), makes it possible for one confusion to give rise to another: <code>u</code> is then confused for “‘normal’ users”: anybody not the owner or in the owning group.</p>
  
  <p>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 <code>o</code> = “owner”, <code>u</code> = “normal users” is so <em>seductive,</em> that they retain some insecurity until enough (sometimes <em>a lot</em> is necessary) rote memorization makes it finally sink in.</p>
  
  <p>What would be a mnemonic or other way to explain it which makes the correct notion <strong>stick</strong> <em>right</em> from the start, so rote memorization isn't necessary?</p>
  
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-31T05:30:23.153Z
Comments.Text: An interesting challenge. Let's see what folks come up with :)
Comments.UserDisplayName: Ben I.
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-31T05:40:55.123Z
Comments.Text: 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>`.
Comments.UserDisplayName: Gypsy Spellweaver
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-31T13:48:22.207Z
Comments.Text: @GypsySpellweaver only that it is **not** a shortcut, but **feature** of the command that is **EXTREMELY** cumbersome to emulate using octal codes.
Comments.UserDisplayName: viuser
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-06-01T01:22:18.703Z
Comments.Text: @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.
Comments.UserDisplayName: ivanivan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-06-01T14:10:47.017Z
Comments.Text: 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.
Comments.UserDisplayName: Michel Billaud
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-06-02T11:10:42.393Z
Comments.Text: @GypsySpellweaver you sound like von neumann: Assembly language is for the feeble minded, real programmers use machine code.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-06-02T17:57:53.157Z
Comments.Text: @ctrl-alt-delor I must be super feeble minded since I don't even like Assembly, though I've done machine and Assembly. The layers of abstraction available in 3rd gen(+) langs is wonderful. In this case, however, if one way is confusing, use the other which while less simple, less confusing.
Comments.UserDisplayName: Gypsy Spellweaver
Tags: <adult-education><command-line>
Title: The confusing Unix permissions terminology
ThreadText: # The confusing Unix permissions terminology
  
  (Asked by: username_0 on 2018-05-31)
  
  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 “**ch**ange **own**er”, 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 **u**ser), 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.
  
  **Tags:** adult-education, command-line
  
  > **Comments:**
  > **username_1**: An interesting challenge. Let's see what folks come up with :)  
  > **username_2**: 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>`.  
  > **username_0**: @username_2 only that it is **not** a shortcut, but **feature** of the command that is **EXTREMELY** cumbersome to emulate using octal codes.  
  > **username_3**: @username_2 - 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.  
  > **username_4**: 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.  
  > **username_5**: @username_2 you sound like von neumann: Assembly language is for the feeble minded, real programmers use machine code.  
  > **username_2**: @username_5 I must be super feeble minded since I don't even like Assembly, though I've done machine and Assembly. The layers of abstraction available in 3rd gen(+) langs is wonderful. In this case, however, if one way is confusing, use the other which while less simple, less confusing.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_8 on 2018-05-31. Score: 8 | Accepted answer
  
  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 **u**ser and **g**roup: `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”.
  
  > **Comments:**
  > **username_9**: So in other words teach **chown = change owner*ship***?  
  
  ---
  
  ### Answer by username_10 on 2018-06-12. Score: 3
  
  > 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).
  
  > **Comments:**
  > **username_1**: 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?  
  > **username_1**: 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.  
  > **username_10**: Done. I'm fairly new here; do the comments get wiped automatically or is that done manually?  
  > **username_1**: 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 :)  
  
  ---
  
  ### Answer by username_6 on 2018-06-01. Score: 0
  
  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.
  
  > **Comments:**
  > **username_1**: 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?  
  > **username_6**: 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.  
  
  ---
  
  ### Answer by username_7 on 2018-06-20. Score: -1
  
  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.
  
  
  ---
  
  