Unix File Permission Primer - Revision history

Pip: /* Extra Property Representations */

2024-12-18T20:02:53Z

Extra Property Representations

Pip: /* Default Permissions */

2024-12-18T19:59:34Z

Default Permissions

Phil: /* Default Permissions */

2020-04-13T15:43:11Z

Default Permissions

Phil: /* Default Permissions */

2020-04-13T15:40:45Z

Default Permissions

Phil.cs.jhu.edu: /* Access Control Lists */

2017-06-12T19:17:47Z

Access Control Lists

Steve410.cs.jhu.edu: /* Default Permissions */

2016-10-11T17:07:34Z

Default Permissions

Phil.cs.jhu.edu at 20:29, 13 September 2016

2016-09-13T20:29:36Z

Phil.cs.jhu.edu: /* Extra Properties */

2016-09-13T20:27:41Z

Extra Properties

Phil.cs.jhu.edu: /* Octal Representation */

2016-09-13T20:19:04Z

Octal Representation

Phil.cs.jhu.edu: /* Symbolic Representation */

2016-09-13T20:06:13Z

Symbolic Representation

@@ Line 156: / Line 156: @@
 ==== Extra Property Representations ====
-In <tt>ls -l</tt> output, set UID and set GID are represented by putting an "'''s'''" in place of the user or group "'''x'''" character.  (If for some reason the object has set UID or set GID without the corresponding execute permission--which is almost always a mistake--the character used is a capital "'''S'''".)  The sticky bit is represented with a "'''t'''" in place of the "other" execute permission.  (Like the other properties, an object with the sticky bit but without "other" execute permission will have a capital "'''T'''".) For example:
+In <tt>ls -l</tt> output, set UID and set GID are represented by putting an "'''s'''" in place of the user or group "'''x'''" character.  (If for some reason the object has set UID or set GID without the corresponding execute permission—which is almost always a mistake—the character used is a capital "'''S'''".)  The sticky bit is represented with a "'''t'''" in place of the "other" execute permission.  (Like the other properties, an object with the sticky bit but without "other" execute permission will have a capital "'''T'''".) For example:
 * <tt>-rw-r-----</tt> is an ordinary file with no extra properties.

@@ Line 117: / Line 117: @@
   umask ''new-permissions''
-To make the change permanent, you'll have to add that command to your shell's initialization file.  On our systems, if you haven't changed your shell, that file will be <tt>~/.cshrc</tt> .
+To make the change permanent, you'll have to add that command to your shell's initialization file.  On our systems, if you haven't changed your shell, that file will be <tt>~/.bashrc</tt> .
 '''Warning''': The default shell on our systems used to be <tt>tcsh</tt>, which ''only'' understands octal notation for permissions.  ''Symbolic notation will not work.''  Many of our accounts still use <code>tcsh</code>.  To determine which shell you're using please see [[Shells Available for CS Accounts (bash, tcsh, etc.)|our shells page]].

@@ Line 119: / Line 119: @@
 To make the change permanent, you'll have to add that command to your shell's initialization file.  On our systems, if you haven't changed your shell, that file will be <tt>~/.cshrc</tt> .
-'''Warning''': The default shell on our systems (<tt>tcsh</tt>) ''only'' understands octal notation for permissions.  ''Symbolic notation will not work.''
+'''Warning''': The default shell on our systems used to be <tt>tcsh</tt>, which ''only'' understands octal notation for permissions.  ''Symbolic notation will not work.''  Many of our accounts still use <code>tcsh</code>.  To determine which shell you're using please see [[Shells Available for CS Accounts (bash, tcsh, etc.)|our shells page]].
 == Changing Permissions ==

@@ Line 103: / Line 103: @@
 When you log in to a system, your default permissions are set by your shell's ''umask''.  The umask serves as a kind of limit on the permissions given to new files and directories.  Without a umask, files would all have permissions <tt>666</tt> (<tt>a=rw</tt> or <tt>u=rw,g=rw,o=rw</tt>) and directories would all have permissions <tt>777</tt> (<tt>a=rwx</tt> or <tt>u=rwx,g=rwx,o=rwx</tt>).  In actuality, when a file or directory is created, the system ''starts'' with those values (<tt>666</tt> for files and <tt>777</tt> for directories), but then applies the umask, which removes some of those starting permissions to arrive at the actual defaults.
-You can view your umask with the <tt>umask</tt> command, which will show the umask in its octal representation.  Many shells (but not the default shell on our systems, <tt>tcsh</tt>) also support running <tt>umask -S</tt> to show the umask in symbolic representation.
+You can view your umask with the <tt>umask</tt> command, which will show the umask in its octal representation.  Many shells (but not <tt>tcsh</tt>, which is used by many accounts on our systems) also support running <tt>umask -S</tt> to show the umask in symbolic representation.
 Unfortunately, the meaning of the umask is different between the octal and symbolic representation.  (Unix is full of such unfortunate contradictions.)  The symbolic representation works as a limit on the permissions.  In symbolic terms, our default umask is <tt>u=rwx,g=,o=</tt>.  The process of applying the symbolic umask is ''logical intersection''; only permissions that are in the starting set ''and'' the umask will be applied to the file or directory being created.

@@ Line 181: / Line 181: @@
 Access Control Lists (ACLs) are a more complex way of managing permissions that work in addition to the standard permissions described above.  They are capable of handing certain situations that are simply not possible with the standard permissions.  Unfortunately, they add a significant amount of complexity, so we don't recommend using them unless there's no other way to accomplish your goals.  (And remember, when in doubt, you can always email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for help with our systems.)
-That said, we do have a limited amount of documentation about using ACLs on our systems.  ''Which'' documentation you need will depend on whether you're using our [[Linux Clients on the CS Undergrad Net|undergrad Linux clients]] or our [[Linux Clients on the CS Grad/Research Net|graduate Linux clients]].
+That said, we do have a limited amount of documentation about using ACLs on our systems.  Please see our page on [[NFSv4 Access Control Lists]].
 === SELinux ===

@@ Line 99: / Line 99: @@
 == Default Permissions ==
-On our systems, the default permissions for files are <tt>600</tt> (<tt>u=rw,g=,o=</tt>) and the default permissions for directories are <tt>700</tt> (<tt>u=rwx,g=,o=</tt>).  Here's how those defaults are set (and how you can change them):
+On ''our'' systems, the default permissions for files are <tt>600</tt> (<tt>u=rw,g=,o=</tt>) and the default permissions for directories are <tt>700</tt> (<tt>u=rwx,g=,o=</tt>).  Here's how those defaults are set (and how you can change them):
 When you log in to a system, your default permissions are set by your shell's ''umask''.  The umask serves as a kind of limit on the permissions given to new files and directories.  Without a umask, files would all have permissions <tt>666</tt> (<tt>a=rw</tt> or <tt>u=rw,g=rw,o=rw</tt>) and directories would all have permissions <tt>777</tt> (<tt>a=rwx</tt> or <tt>u=rwx,g=rwx,o=rwx</tt>).  In actuality, when a file or directory is created, the system ''starts'' with those values (<tt>666</tt> for files and <tt>777</tt> for directories), but then applies the umask, which removes some of those starting permissions to arrive at the actual defaults.

← Older revision		Revision as of 20:29, 13 September 2016
Line 191:		Line 191:

	Fortunately, you should never need to worry about SELinux. We use it on our systems, but the systems should be configured in such a way that SELinux never prevents you from doing something that you should be allowed to do. (We're mentioning it here just so you know what that little dot means.)		Fortunately, you should never need to worry about SELinux. We use it on our systems, but the systems should be configured in such a way that SELinux never prevents you from doing something that you should be allowed to do. (We're mentioning it here just so you know what that little dot means.)
		+
		+	[[Category:Reference Material]]

@@ Line 144: / Line 144: @@
 ** On a file: When the file is run as a program, it runs under the account of the file owner, not the account of the person running it.  This is often used for controlled access to things with restricted permissions.
 *** e.g. Only <tt>root</tt> can edit the password database (otherwise you could change someone else's password), but the <tt>passwd</tt> program is set UID to <tt>root</tt> so that it can change your password (and only ''your'' password) for you.
-** On a directory: Any file created in the directory (by someone who has write access to the directory) will be owned by the account that owns the directory.  (Under normal circumstances, when you create a file, your account will automatically own that file.)
+** On a directory: Any file created in the directory (by someone who has write access to the directory) will be owned by the account that owns the directory.  (Under normal circumstances, when you create a file, ''your'' account will automatically own that file.)
 * '''Set GID'''
 ** On a file: When the file is run as a program, it runs under the group of the file, not the group of the person running it.  Obviously, this is analogous to the set UID property, but for groups.

@@ Line 73: / Line 73: @@
 {|class="wikitable" style="text-align: center"
 |-
-!!!read!!write!!execute|| !!sum
+!!!read<br>(4)!!write<br>(2)!!execute<br>(1)|| !!sum
 |-
 !user

@@ Line 54: / Line 54: @@
 === Symbolic Representation ===
-In the symbolic representation, each permission set and permission is shortened to a single character; the "r", "w", and "x" you might expect for the permissions, and "u", "g", and "o" for the "user", "group", and "other" sets.  You can either specify permissions as a change from the current or default value with "+" or "-", or you can specify them exactly with "=".  Different sets are separated by commas.  As a special case, you can use the "a" character to represent "all" sets; it will apply its permissions to all three of the "user", "group", and "other" permission sets.
+In the symbolic representation, each permission and permission set is shortened to a single character; the "r", "w", and "x" you might expect for the permissions, and "u", "g", and "o" for the "user", "group", and "other" sets.  You can either specify permissions as a change from an existing value with "+" or "-", or you can specify them exactly with "=".  Different sets are separated by commas.  As a special case, you can use the "a" character to represent "all" sets; it will apply its permissions to all three of the "user", "group", and "other" permission sets.
 Here are some examples:
-* <tt>u=rwx,g=,o=rx</tt> - This specifies permissions exactly and would be shown by <tt>ls -l</tt> as "<tt>-rwx---r-x</tt>".  The owning account has full permissions, members of the owning group have no permissions, and everyone else has read and execute permissions.
+* <tt>u=rwx,g=,o=rx</tt> - This specifies all of the permissions exactly and would be shown by <tt>ls -l</tt> as "<tt>-rwx---r-x</tt>".  The owning account has full permissions, members of the owning group have no permissions, and everyone else has read and execute permissions.
-* <tt>g-w,o-rwx</tt> - This is a modification of an existing set of permissions.  Write permission is being removed from the "group" permission set and all permissions are being removed from the "other" set.
+* <tt>g-w,o-rwx</tt> - This is a modification of an existing set of permissions.  Write permission is being removed from the "group" permission set and all three permissions are being removed from the "other" set.
 * <tt>u-w,g+r</tt> - Also a modification of an existing set of permissions.  The owner no longer has write access, but members of the owning group can now read the file.
 * <tt>a+r,a-w</tt> - Another modification of an existing set of permissions.  Anyone can now read the file, but no one (not even the owner) can write to it.