Differences between version 15 and predecessor to the previous major change of FilePermissions.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Monday, April 23, 2007 2:10:15 pm | by AristotlePagaltzis | Revert |
| Older page: | version 14 | Last edited on Thursday, April 19, 2007 9:45:38 am | by BenStaz | Revert |
@@ -11,78 +11,61 @@
| <tt>1</tt> | number of links
| <tt>mythtv</tt> | file owner
| <tt>users</tt> | file-owning group
| <tt>1706</tt> | file size
-| <tt>2005-10-13 14:01</tt> | creation time
+| <tt>2005-10-13 
14:01</tt> | creation time
| <tt>release.keys</tt> | filename
?>
-This page concentrates on the first bit: the file permissions
.
+This page concentrates on the first bit.
+
+!!! File permissions
[UNIX] file permissions are made up of three groups: the __u__ser who owns the file, the __g__roup that the file belongs to, and __o__ther people. These letters are important as you can use them to instruct [chmod(1)] change the permission of the file.
For each part, you have __r__ead, __w__rite, and e__x__ecute access. These are displayed as <tt>rwx</tt>.
-Typically, system data files as well files served from a WebServer or such have <tt>-rw-r--r--</tt>, ie. they're readable for everyone but writable only for their owner; files with private data have <tt>-rw-------</tt>: readable and writeable only for their owner and noone else. Directories and executable files generally have <tt>-rwxr-xr-x</tt>: they're readable and executable for everyone but writable only for their owl
-The executable permission on directories means that it may be used as part of a path; f.ex., if user <tt>bob</tt> does not have execute permission for <tt>/var/queue/joe</tt>, he will not be able to read <tt>/var/queue/joe/msg.371</tt>, even if he has read permission on the file itself. If <tt>/var/queue/joe</tt> has the execute permission set, but not the read permission, then <tt>bob</tt> will not be able to get a directory listing. ''However'', if he knows the name of a file in that directory, eg. he knows that <tt>/var/queue/joe/msg.371</tt> exists, then he can still reach it to read it (assuming he has read permission for that file)
.
+Typically, system data files as well files served from a WebServer or such have <tt>-rw-r--r--</tt>, ie. they're readable for everyone but writable only for their owner; files with private data have <tt>-rw-------</tt>: readable and writeable only for their owner and noone else. Directories and executable files generally have <tt>-rwxr-xr-x</tt>: they're readable and executable for everyone but writable only for their owner
.
-!Files
+!!! Effects of permissions on directories
-*r - This tells us that the file can be read.
-*w - This tells us that the file can be written
to.
-*x - This tells us that the
file may be executed
.
+It's easy
to understand what a particular set of permissions means for a
file. On directories, it's less intuitive, so here are some explanations:
-!Directories
+Having __r__ead permission on a directory means that you can see the list of files in that directory. It doesn't mean anything else; in particular, it doesn't mean that you can open the files. Being able to read a directory means being able to list the files contained in the directory – no more, no less.
-Here are some examples of
the effects of various combinations:
+Having __w__rite access means that you can modify
the directory. That means you can create or delete files or directories in it. ''You can delete a file even if you do not have any permissions to write or even read the file'' as long as you have write permission for the directory in which the file resides.
- * r--
+The e__x__ecutable permission on directories means that you may use it as part of a path. F.ex., if user <tt>bob</tt> does not have execute permission for <tt>/var/queue/joe</tt>, he will not be able to read <tt>/var/queue/joe/msg.371</tt>, even if he has read permission on the file itself.
- The user, group, or other with these permissions may list the contents
of the directory, but nothing else. The files in the directory can't be
read, changed, deleted, or manipulated in any way. The only permitted action is reading the directory itself, that is, seeing what files it contains.
+!! Absence
of read permission
- * rw-
+If the <tt>/var/queue/joe</tt> directory from the last example has the execute permission set, but __not__ the read permission, then <tt>bob</tt> will not be able to get a directory listing. (Remember? Read permission means you can get a directory listing.) ''However'', if he knows the name of a file in that directory, eg. he knows that <tt>/var/queue/joe/msg.371</tt> exists, and he has read permission for the file itself, then he can still read the file. Also, if he has write permission to the directory, he will be able to delete <tt>/var/queue/joe/msg.371</tt>, even though he cannot get a directory listing.
- Write permission has no effect in the absence of execute permission, so this mode behaves just like the above mode.
+!!! Modifying permissions
- *
r-
x
+Permissions are altered on the [Shell] using [chmod(1)]. (''Missing here is an explanation of the 4=
r, 2=w, 1=
x mapping. Feel free to AddToMe.'')
- This mode permits
the files in a directory to be listed
, and permits access to those files
. However
, files can
't be created or deleted. Access means that you can view, change, or execute the files as permitted by the files' own permissions
.
+Generally,
the fewer permissions you grant
, the better
. Most importantly
, there
's almost never a good reason to grant write permission to "other people"
.
- * --x
+!!! Recursive [chmod(1)]
- Files in this directory can be accessed
, but
the contents of
the directory can't be listed
, so you have
to know what filename
you're looking for in advance (unless you're
a good guesser)
. Files
can't be created or deleted
.
+[chmod(1)] has a potentially very convenient switch: <tt>-R</tt>
, which, as you'll suspect if you've used other [UNIX] tools, means "recurse into directories and apply
the change to
the entire
directory tree." However
, because directories need
to be executable before
you can refer to any of the files inside them, it would sometimes seem that this convenient switch cannot be used. F.ex., saying <tt>chmod -R
a-x
./foo/</tt> isn't very useful because that will make everything inside <tt>foo</tt> non-executable, including directories, which means you
can't access any of it
.
- * rwx
+However, modern [chmod(1)]s understand a special pseudo-permission, called <tt>X</tt> (eg. uppercase X as opposed to <tt>x</tt>). It means "executable, but only when operating on a directory; no change otherwise". That way, you can say <tt>chmod -R a-x,a+X ./foo/</tt>, which will make [chmod(1)] remove the executable bit from every file but then also ''set'' the executable bit if it's a directory.
- You can do anything you want with the files in
this directory
, as long as
it's permitted by the permissions on the files themselves.
-
-If you have execute permissions
to a directory, file permissions for that directory become relevant. Otherwise file permissions just don't matter; you can't access the files anyway.
-
-!chmod
-
-Permissions are altered on the
[Shell] using [chmod
(1)]. (''Missing here is an explanation of the 4=r, 2=w, 1=x mapping. Feel free
to AddToMe
.'')
-
-Generally
, the fewer permissions you grant, the better. Most importantly, there's almost never a good reason to grant write permission to "other people"
.
+Before
this feature was added
, it was sometimes necessary
to go through inconvenient contortions involing
[find
(1)] in order
to operate only on files or only on directories
. While that
's still occasionally necessary
, those occasions are now much rarer
.
!!! Sticky and setuid
-There are actually two more permissions that are almost never useful outside of system files (so if you're not in this to learn how [UNIX] works, you can skip this part)
.
+There are actually two more permissions that are almost never useful outside of system files.
The __s__etuid bit is shown with an <tt>s</tt> in directory listings. It specifies that when you execute the file, you assume the identity of the owner of the file. For example, if a file is owned by <tt>root</tt> and has the setuid permission set, it will run as <tt>root</tt> when you execute it, regardless of what your identity is. This is a way to allow regular users to do priviledged things; however it can easily lead to gaping security holes.
The s__t__icky bit is shown with a <tt>t</tt> in directory listings is used for some widely shared system directories. It specifies that only the owner of a file can delete it. Normally, anyone who can create a file in a directory can delete ''any'' file in that directory. (To be precise, the owner of a directory with the sticky bit set can also delete any of the files in it.)
-
-!!! Recursive [chmod(1)]
-
-[chmod(1)] has a potentially very convenient switch: <tt>-R</tt>, which, as you'll suspect if you've used other [UNIX] tools, means "recurse into directories and apply the change to the entire directory tree." However, because directories need to be executable before you can refer to any of the files inside them, it would sometimes seem that this convenient switch cannot be used. F.ex., saying <tt>chmod -R a-x ./foo/</tt> isn't very useful because that will make everything inside <tt>foo</tt> non-executable, including directories, which means you can't access any of it.
-
-However, modern [chmod(1)]s understand a special pseudo-permission, called <tt>X</tt> (eg. uppercase X as opposed to <tt>x</tt>). It means "executable, but only when operating on a directory; no change otherwise". That way, you can say <tt>chmod -R a-x,a+X ./foo/</tt>, which will make [chmod(1)] remove the executable bit from every file but then also ''set'' the executable bit if it's a directory.
-
-Before this, it was sometimes necessary to go through inconvenient contortions involing [find(1)] in order to operate only on files or only on directories. While that's still occasionally necessary, those occasions are now much rarer.
!!! See also
* [An excellent guide to permissions at Greg's wiki | http://wooledge.org/mywiki/Permissions]
* [A Linux Focus article about file permissions | http://www.linuxfocus.org/English/January1999/article77.html]
----
CategoryBeginners
