rsnt_translations
56,420
edits
No edit summary |
No edit summary |
||
Line 29: | Line 29: | ||
<!--T:4--> | <!--T:4--> | ||
To change the permissions of a file or directory you can use the command <code>chmod</code> along with the user category, a plus or minus sign indicating that permission is granted or withdrawn, and the nature of the permission: read (<code>r</code>), write (<code>w</code>) or execute (<code>x</code>). For the user category, we use the abbreviations < | To change the permissions of a file or directory you can use the command <code>chmod</code> along with the user category, a plus or minus sign indicating that permission is granted or withdrawn, and the nature of the permission: read (<code>r</code>), write (<code>w</code>) or execute (<code>x</code>). For the user category, we use the abbreviations <code>u</code> for the owner (user), <code>g</code> for the group and <code>o</code> for others, i.e. everyone else on the cluster. So a command like | ||
{{Command|chmod g+r file.txt}} | {{Command|chmod g+r file.txt}} | ||
would grant read permission to all members of the group that file.txt belongs to, while | would grant read permission to all members of the group that file.txt belongs to, while | ||
{{Command|chmod o-x script.py}} | {{Command|chmod o-x script.py}} | ||
would withdraw execute permission for the file script.py to everyone but the owner and the group. We can also use the user category < | would withdraw execute permission for the file script.py to everyone but the owner and the group. We can also use the user category <code>a</code> to denote everyone (all), thus | ||
{{Command|chmod a+r file.txt}} | {{Command|chmod a+r file.txt}} | ||
grants everyone on the cluster the right to read file.txt. | grants everyone on the cluster the right to read file.txt. | ||
Line 44: | Line 44: | ||
<!--T:7--> | <!--T:7--> | ||
You can alter these permissions using the command < | You can alter these permissions using the command <code>chmod</code> in conjunction with the octal notation discussed above, so for example | ||
{{Command|chmod 770 name_of_file}} | {{Command|chmod 770 name_of_file}} | ||
means that everyone in your group now has the right to read, write and execute this file. Naturally, you can only modify the permissions of a file or directory you own. You can also alter the group by means of the command < | means that everyone in your group now has the right to read, write and execute this file. Naturally, you can only modify the permissions of a file or directory you own. You can also alter the group by means of the command <code>chgrp</code>. | ||
===The sticky bit=== <!--T:13--> | ===The sticky bit=== <!--T:13--> | ||
Line 71: | Line 71: | ||
<!--T:18--> | <!--T:18--> | ||
If the < | If the <code>setGID</code> bit is enabled for a directory, new files and directories in that directory will be created with the same group ownership as the directory. To illustrate the use of this mode, let us walk through an example. | ||
<!--T:17--> | <!--T:17--> | ||
Line 90: | Line 90: | ||
-rw-rw-r-- 1 someuser someuser 0 Oct 13 19:38 test01.txt | -rw-rw-r-- 1 someuser someuser 0 Oct 13 19:38 test01.txt | ||
</source> | </source> | ||
If we are in <code>/project</code> this is probably not what we want. We want a newly created file to belong to the same group as the parent folder. Enable the < | If we are in <code>/project</code> this is probably not what we want. We want a newly created file to belong to the same group as the parent folder. Enable the <code>setGID</code> permission on the parent directory like so: | ||
<source lang="console"> | <source lang="console"> | ||
[someuser@server]$ chmod g+s dirTest | [someuser@server]$ chmod g+s dirTest | ||
Line 103: | Line 103: | ||
-rw-rw-r-- 1 someuser def-someuser 0 Oct 13 19:39 test02.txt | -rw-rw-r-- 1 someuser def-someuser 0 Oct 13 19:39 test02.txt | ||
</source> | </source> | ||
If we create a directory inside a directory with the < | If we create a directory inside a directory with the <code>setGID</code> enabled, it will have the same group as the parent folder and also have its <code>setGID</code> enabled. | ||
<source lang="console"> | <source lang="console"> | ||
[someuser@server]$ mkdir dirTest/dirChild | [someuser@server]$ mkdir dirTest/dirChild | ||
Line 111: | Line 111: | ||
drwxrwsr-x 1 someuser def-someuser 0 Oct 13 19:39 dirChild | drwxrwsr-x 1 someuser def-someuser 0 Oct 13 19:39 dirChild | ||
</source> | </source> | ||
Finally, it can be important to note the difference between <code>S</code> (uppercase S) and <code>s</code>. The uppercase S indicates that execute permissions have been removed from the directory but the < | Finally, it can be important to note the difference between <code>S</code> (uppercase S) and <code>s</code>. The uppercase S indicates that execute permissions have been removed from the directory but the <code>setGID</code> is still in place. It can be easy to miss this and may result in unexpected problems, such as others in the group not being able to access files within your directory. | ||
<source lang="console"> | <source lang="console"> | ||
[someuser@server]$ chmod g-x dirTest/ | [someuser@server]$ chmod g-x dirTest/ | ||
Line 119: | Line 119: | ||
=== Set User ID bit === <!--T:47--> | === Set User ID bit === <!--T:47--> | ||
The < | The <code>setUID</code> bit <b>will not work</b> on our clusters. | ||
Its usual behaviour is completely disabled, for security reasons. | Its usual behaviour is completely disabled, for security reasons. | ||