| Rev | Author | # | Line |
|---|---|---|---|
| 8 | AristotlePagaltzis | 1 | Here's a directory listing as produced by <tt>ls -l</tt>: |
| 6 | IanMcDonald | 2 | |
| 3 | <verbatim> | ||
| 4 | -rw-r--r-- 1 mythtv users 1706 2005-10-13 14:01 release.keys | ||
| 5 | </verbatim> | ||
| 6 | |||
| 8 | AristotlePagaltzis | 7 | Here, the various columns mean the following: |
| 8 | |||
| 9 | <?plugin OldStyleTable border||=0 | ||
| 10 | | <tt>-rw-r--r--</tt> | File permissions | ||
| 11 | | <tt>1</tt> | number of links | ||
| 12 | | <tt>mythtv</tt> | file owner | ||
| 13 | | <tt>users</tt> | file-owning group | ||
| 14 | | <tt>1706</tt> | file size | ||
| 15 | AristotlePagaltzis | 15 | | <tt>2005-10-13 14:01</tt> | creation time |
| 8 | AristotlePagaltzis | 16 | | <tt>release.keys</tt> | filename |
| 6 | IanMcDonald | 17 | ?> |
| 18 | |||
| 15 | AristotlePagaltzis | 19 | This page concentrates on the first bit. |
| 20 | |||
| 21 | !!! File permissions | ||
| 8 | AristotlePagaltzis | 22 | |
| 23 | [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. | ||
| 24 | |||
| 25 | For each part, you have __r__ead, __w__rite, and e__x__ecute access. These are displayed as <tt>rwx</tt>. | ||
| 26 | |||
| 15 | AristotlePagaltzis | 27 | 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. |
| 13 | BenStaz | 28 | |
| 15 | AristotlePagaltzis | 29 | !!! Effects of permissions on directories |
| 13 | BenStaz | 30 | |
| 15 | AristotlePagaltzis | 31 | 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: |
| 13 | BenStaz | 32 | |
| 17 | LawrenceDoliveiro | 33 | 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, or get information about them via stat(2). Being able to read a directory means being able to list the files contained in the directory – no more, no less. |
| 13 | BenStaz | 34 | |
| 18 | LawrenceDoliveiro | 35 | Having __w__rite access on its own means nothing. But together with e__x__ecute access, it allows you to 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 and execute permission for the directory in which the file resides. |
| 13 | BenStaz | 36 | |
| 17 | LawrenceDoliveiro | 37 | 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 or stat <tt>/var/queue/joe/msg.371</tt>, even if he has read permission on the file itself. |
| 13 | BenStaz | 38 | |
| 15 | AristotlePagaltzis | 39 | !! Absence of read permission |
| 13 | BenStaz | 40 | |
| 15 | AristotlePagaltzis | 41 | 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. |
| 13 | BenStaz | 42 | |
| 15 | AristotlePagaltzis | 43 | !!! Modifying permissions |
| 13 | BenStaz | 44 | |
| 15 | AristotlePagaltzis | 45 | 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.'') |
| 13 | BenStaz | 46 | |
| 15 | AristotlePagaltzis | 47 | Generally, the fewer permissions you grant, the better. Most importantly, there's almost never a good reason to grant write permission to "other people". |
| 13 | BenStaz | 48 | |
| 15 | AristotlePagaltzis | 49 | !!! Recursive [chmod(1)] |
| 13 | BenStaz | 50 | |
| 15 | AristotlePagaltzis | 51 | [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. |
| 13 | BenStaz | 52 | |
| 15 | AristotlePagaltzis | 53 | 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. |
| 13 | BenStaz | 54 | |
| 15 | AristotlePagaltzis | 55 | 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. |
| 6 | IanMcDonald | 56 | |
| 8 | AristotlePagaltzis | 57 | !!! Sticky and setuid |
| 6 | IanMcDonald | 58 | |
| 15 | AristotlePagaltzis | 59 | There are actually two more permissions that are almost never useful outside of system files. |
| 6 | IanMcDonald | 60 | |
| 8 | AristotlePagaltzis | 61 | 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. |
| 6 | IanMcDonald | 62 | |
| 8 | AristotlePagaltzis | 63 | 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.) |
| 6 | IanMcDonald | 64 | |
| 8 | AristotlePagaltzis | 65 | !!! See also |
| 6 | IanMcDonald | 66 | |
| 16 | AristotlePagaltzis | 67 | * [Daniel Miessler's great quick refresher on permissions | http://dmiessler.com/study/unixlinux_permissions/] |
| 8 | AristotlePagaltzis | 68 | * [An excellent guide to permissions at Greg's wiki | http://wooledge.org/mywiki/Permissions] |
| 69 | * [A Linux Focus article about file permissions | http://www.linuxfocus.org/English/January1999/article77.html] | ||
| 6 | IanMcDonald | 70 | |
| 71 | ---- | ||
| 72 | CategoryBeginners |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 2 times)