Menu
▾
▴
[Proftpd-docs] www.proftpd.org/docs/howto Umask.html,1.2,1.3
|
From: TJ S. <cas...@us...> - 2012-03-26 16:25:59
|
Update of /cvsroot/pdd/www.proftpd.org/docs/howto In directory vz-cvs-3.sog:/tmp/cvs-serv11269/howto Modified Files: Umask.html Log Message: Updating website copies of mod_core, Umask docs. Index: Umask.html =================================================================== RCS file: /cvsroot/pdd/www.proftpd.org/docs/howto/Umask.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- Umask.html 5 Jan 2010 17:06:09 -0000 1.2 +++ Umask.html 26 Mar 2012 16:25:56 -0000 1.3 @@ -13,18 +13,22 @@ <hr> <p> -ProFTPD's <a href="http://www.proftpd.org/docs/directives/linked/config_ref_Umask.html"><code>Umask</code></a> configuration directive is used to set the -file permission bits on newly created files and directories. However, the way -in which <code>Umask</code> is to be used is not entirely straightforward. +ProFTPD's <a href="../modules/mod_core.html#Umask"><code>Umask</code></a> +configuration directive is used to set the file permission bits on newly +created files and directories. However, the way in which <code>Umask</code> +is to be used is not entirely straightforward. <p> <code>Umask</code> is used to set the value that <code>proftpd</code> will use when calling <code>umask(2)</code>. The <code>umask(2)</code> function -works something like this: <code><i>mode - umask</i></code>. -(Technically, the operation is <code><i>mode & ~umask</i></code>). Thus, with -a <i>mode</i> of <code>0666</code>, and a <i>umask</i> of <code>0022</code>, -the permissions on the newly created file will be <code>0644</code> -(<i>e.g.</i> <code>rw-r--r--</code>). +works something like this: +<pre> + new file mode = <i>base-mode</i> - <i>umask</i> +</pre> +(Technically, the operation is <code><i>base-mode & ~umask</i></code>). +Thus, with a <i>base-mode</i> of <code>0666</code>, and a <i>umask</i> of +<code>0022</code>, the permissions on the newly created file will be +<code>0644</code> (<i>e.g.</i> <code>rw-r--r--</code>). <p> A quick review of permission bits: @@ -42,22 +46,67 @@ <code>5 = 4 + 1</code> (<i>e.g.</i> <code>r-x</code>). And finally, other or world permissions are specified using the last bit, which in the example is <code>0</code> (no permissions, <i>e.g.</i> <code>---</code>). -The full represenation of a <i>mode</i> of <code>0750</code>, as one would -see it in a directory listing, would thus be: <code>rwxr-x---</code>. <p> -The <code>proftpd</code> daemon always starts with a base <i>mode</i> of +Here are some concrete examples to help illustrate things: +<p> +<table border=1> + <tr> + <td><b>Mode</b></td> + <td><b>Label</b></td> + <td><b>Description</b></td> + </tr> + + <tr> + <td> <code>0777</code> </td> + <td> <code>rwxrwxrwx</code> </td> + <td>read/write/execute permissions for user owner, group owner, and other</td> + </tr> + + <tr> + <td> <code>0666</code> </td> + <td> <code>rw-rw-rw-</code> </td> + <td>read/write permissions for user owner, group owner, and other</td> + </tr> + + <tr> + <td> <code>0755</code> </td> + <td> <code>rwxr-xr-x</code> </td> + <td>read/write/execute permissions for user owner, read/execute permissions for group owner and other</td> + </tr> + + <tr> + <td> <code>0750</code> </td> + <td> <code>rwxr-x---</code> </td> + <td>read/write/execute permissions for user owner, read permission for group owner, no permissions for other</td> + </tr> + + <tr> + <td> <code>0644</code> </td> + <td> <code>rw-r--r--</code> </td> + <td>read/write permissions for user owner, read permission for group owner and other</td> + </tr> + + <tr> + <td> <code>0511</code> </td> + <td> <code>r-x--x--x</code> </td> + <td>read/execute permissions for user owner, execute permission for group owner and other</td> + </tr> +</table> + +<p> +The <code>proftpd</code> daemon always starts with a <i>base-mode</i> of <code>0666</code> when creating files. Note that <code>Umask</code> can only -be used to "take away" permissions granted by the base -<i>mode</i>; it cannot be used to add permissions that are not there. This -means that files uploaded to a <code>proftpd</code> server will never have the -execute permission enabled by default (the base <i>mode</i> is does not have -any execute bits enabled). This is a conscious security design decision. For -directories, the base <i>mode</i> is <code>0777</code>. The <i>umask</i> used -for directories can be configured using the optional second parameter to the -<code>Umask</code> directive; if this second parameter is not used, the -<i>umask</i> used for created directories will default to the same -<i>umask</i> as used for files. +be used to "take away" permissions granted by the <i>base-mode</i>; +it cannot be used to add permissions that are not there. This means that +files uploaded to a <code>proftpd</code> server will never have the execute +permission enabled by default, since the <code>0666</code> <i>base-mode</i> +does not have any execute bits enabled). This is a conscious security design +decision. For directories, a different <i>base-mode</i> of <code>0777</code> +is used. The <i>umask</i> used for directories can be configured using the +optional second parameter to the <code>Umask</code> directive; if this second +parameter is not used, the <i>umask</i> used for created directories will +default to the same <i>umask</i> as used for files. <p> If it is necessary to make uploaded files executable, the @@ -80,6 +129,53 @@ deprecated (as of <code>proftpd-1.2.2rc2</code>) <code>AllowChmod</code> configuration directive. +<p> +<b>Examples of Using the <code>Umask</code> Directive</b><br> +You have just installed <code>proftpd</code>, and now need to figure out what +permissions file/directories created on your FTP server should have. As +a conscientious FTP server administrator, you want files/directories to +have the minimum necessary permissions (rather than letting users have access +to files/directories that they do not need). + +<p> +If only the user who creates the files and directories should have full +access, <i>e.g.</i> so they can read and write their own files, then you might +use: +<pre> + # Only the user can see their own files/directories + Umask 0066 0077 +</pre> +With this configuration, a newly uploaded file would have <code>0600</code> +(<code>rw-------</code>) permissions: +<pre> + 0600 = 0666 - 0066 +</pre> +and a newly created directory would have <code>0700</code> +(<code>rwx------</code>) permissions: +<pre> + 0700 = 0777 - 0077 +</pre> + +<p> +Another common case is where you have many users who are uploading files +for sharing with other users. So you want the files to be readable by +everyone, but only the user who uploaded the file should have permission for +writing/changing the file. For this, you might use: +<pre> + # Only the user can change their own files + Umask 0022 +</pre> +With this configuration, a newly uploaded file would have <code>0644</code> +(<code>rw-r--r--</code>) permissions: +<pre> + 0644 = 0666 - 0022 +</pre> +and a newly created directory would have <code>0755</code> +(<code>rwxr-xr-x</code>) permissions: +<pre> + 0755 = 0777 - 0022 +</pre> + <p><a name="FAQ"></a> <b>Frequently Asked Questions</b><br> @@ -97,6 +193,42 @@ <code>SITE CHMOD</code> command to change the permissions on the file to have the execute permissions. +<p><a name="UmaskDeletePermission"> +<font color=red>Question</font>: I have a <code>Umask</code> value of +<code>0066</code>, so that only I have read/write permissions on my files. But other users can delete my files! Is this a <code>proftpd</code> bug?<br> +<font color=blue>Answer</font>: No. The permission for deleting a file is +<b>not</b> governed by the write permission on the deleted file; it is +controlled by the write permission <i>on the directory containing the file</i>. + +<p> +If you think of a directory as a "table of contents", with entries for each +of the files in that directory, then deleting a file means deleting the entry +for that file from the "table of contents", which is a write on the directory +(not on the deleted file). + +<p> +Let's assume that your files were in a directory whose permissions were +<code>0777</code> (<code>rwxrwxrwx</code>). This means that everyone has +write permissions in that directory. It also means that everyone can +delete files from that directory. + +<p> +Now let's assume that your files instead were in a directory whose permissions +where <code>0755</code> (<code>rwxr-xr-x</code>). This means that only the +user owner of the directory can delete files from that directory, and no one +else. + +<p> +For directories which contain files from different users, one of the +little-known (and very useful) permissions to have for the directory is +<code>1777</code> (<code>rwxrwxrwt</code>). The leading 1 (and <code>t</code>) +indicates the "sticky bit". This obscure bit is little used these days, +<i>except</i> in this useful configuration. When the sticky bit is set on +a directory (making it a "sticky directory"), normal users may not delete or +rename files of other users in that directory. Because of this property, +"sticky directories" are quite useful as shared directories (<i>e.g.</i> +<code>/tmp</code>). + <p> <hr> Last Updated: <i>$Date$</i><br> |
