Sharing data: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Created page with "Having to share some but not all of your data with a colleague or other research group is a common occurrence and Compute Canada systems provide a variety of mechanisms to fac...")
 
(copyediting)
Line 1: Line 1:
Having to share some but not all of your data with a colleague or other research group is a common occurrence and Compute Canada systems provide a variety of mechanisms to facilitate this data sharing with colleagues.
Having to share some but not all of your data with a colleague or another research group is a common occurrence. Compute Canada systems provide a variety of mechanisms to facilitate this data sharing with colleagues.


==Permissions==
==Permissions==


Like most modern filesystems, those used on the servers of Compute Canada include the idea of permissions to read, write and execute files and directories. When you attempt to read, modify or delete file or descend into a directory the Linux kernel first verifies that you have the right to do this and if not, you'll see the error message "Permission denied". For every given filesystem object, there are three classes of users: the object's owner (normally the user who created the file or directory), the owner's group and finally everyone else. Each of these different user classes can have the right to read, write or execute a filesystem object, so that all told there are nine permissions associated with each such object.
Like most modern filesystems, those used on the servers of Compute Canada support the idea of permissions to read, write, and execute files and directories. When you attempt to read, modify or delete a file, or access a directory, e.g. with <tt>cd</tt>, the Linux kernel first verifies that you have the right to do this. If not, you'll see the error message "Permission denied". For each filesystem object (file or directory) there are three classes of users:  
# the object's owner --- normally the user who created the object,
# members of the object's group --- normally the same as the owner's group, and
# everyone else.
Each of these classes of users may have the right to read, write, or execute the object. Three classes of users times three types of permission means there are nine permissions associated with each object.


You can see what the current permissions are for a filesystem object with the command  
You can see what the current permissions are for a filesystem object with the command  
{{Command|ls -l name_of_object}}  
{{Command|ls -l name_of_object}}  
which will print out the permissions for the owner, the group and everyone else, for example <tt>-rw-r--r--</tt> for a file that the owner can read and write but not execute and for which everyone else can only read. You'll also see printed out the name of the object's owner and the group. It's common for people to use "octal notation" when referring to Unix filesystem permissions. In this case, we use three bits to represent the permissions for each category of user, with these three bits then interpreted as a number from 0 to 7 using the formula (read_bit)*2^2 + (write_bit)*2^1 + (execute_bit)*2^0. The file permissions given in the above example would have the octal representation 1*2^2 + 1*2^1 + 0*2^0 = 6 for the owner and 1*2^2 + 0*2^1 + 0*2^0 = 4 for the group and everyone else, so 644 overall. Note that to be able to exercise your rights on a file, you also need to be able to access the directory in which it resides, which means having both read and execute permission (or "5" in octal notation) on the directory in question.  
which will print out the permissions for the owner, the group, and everyone else. For example, a file with permissions <tt>-rw-r--r--</tt> means the owner can read it and write it but not execute it, and the group members and everyone else can only read the file. You'll also see printed out the name of the object's owner and the group.  
 
It's common for people to use "octal notation" when referring to Unix filesystem permissions. In this case, we use three bits to represent the permissions for each category of user, with these three bits then interpreted as a number from 0 to 7 using the formula (read_bit)*4 + (write_bit)*2 + (execute_bit)*1. In the above example the octal representation would be 4+2+0 = 6 for the owner and 4+0+0 = 4 for the group and everyone else, so 644 overall.  
 
Note that to be able to exercise your rights on a file, you also need to be able to access the directory in which it resides. This means having both read and execute permission ("5" or "7" in octal notation) on the directory in question.  


You can alter these permissions using the command <tt>chmod</tt> in conjunction with the octal notation discussed above, so for example  
You can alter these permissions using the command <tt>chmod</tt> in conjunction with the octal notation discussed above, so for example  
{{Command|chmod 777 name_of_file}}  
{{Command|chmod 777 name_of_file}}  
means that everyone on the machine 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 and you can also alter the owner and group by means of the commands <tt>chown</tt> and <tt>chgrp</tt> respectively.   
means that everyone on the machine 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 owner and group by means of the commands <tt>chown</tt> and <tt>chgrp</tt> respectively.   


The file permissions discussed above have been available in Unix-like operating systems for decades now but they are very coarse-grained since the whole set of users is divided into just three categories: the owner, a group and everyone else. What if I want to allow a single user who isn't in my group to read a file? Do I really need to make the file readable by everyone in that case? Fortunately, the machines at Compute Canada offer what are called "access control lists" (ACLs) to enable extended permissions that are much more fine-grained and can be set on a user-by-user basis if desired. The two commands needed to manipulate these extended permissions are <tt>getfacl</tt> and <tt>setfacl</tt> to see and alter the ACL permissions respectively. If I want to allow a single person with username smithj to have read and execute permission on the file my_script.py I can achieve this with the command
The file permissions discussed above have been available in Unix-like operating systems for decades now but they are very coarse-grained. The whole set of users is divided into just three categories: the owner, the group, and everyone else. What if I want to allow a single user who isn't in my group to read a file? Do I really need to make the file readable by everyone in that case? No. The Compute Canada's national systems offer "access control lists" (ACLs) to enable permissions to be set on a user-by-user basis if desired. The two commands needed to manipulate these extended permissions are  
* <tt>getfacl</tt> to see the ACL permissions, and  
* <tt>setfacl</tt> to alter them.  
If I want to allow a single person with username <tt>smithj</tt> to have read and execute permission on the file <tt>my_script.py</tt> I can achieve this with the command
{{Command|setfacl -m u:smithj:rx my_script.py}}
{{Command|setfacl -m u:smithj:rx my_script.py}}

Revision as of 14:24, 28 February 2017

Having to share some but not all of your data with a colleague or another research group is a common occurrence. Compute Canada systems provide a variety of mechanisms to facilitate this data sharing with colleagues.

Permissions

Like most modern filesystems, those used on the servers of Compute Canada support the idea of permissions to read, write, and execute files and directories. When you attempt to read, modify or delete a file, or access a directory, e.g. with cd, the Linux kernel first verifies that you have the right to do this. If not, you'll see the error message "Permission denied". For each filesystem object (file or directory) there are three classes of users:

  1. the object's owner --- normally the user who created the object,
  2. members of the object's group --- normally the same as the owner's group, and
  3. everyone else.

Each of these classes of users may have the right to read, write, or execute the object. Three classes of users times three types of permission means there are nine permissions associated with each object.

You can see what the current permissions are for a filesystem object with the command

Question.png
[name@server ~]$ ls -l name_of_object

which will print out the permissions for the owner, the group, and everyone else. For example, a file with permissions -rw-r--r-- means the owner can read it and write it but not execute it, and the group members and everyone else can only read the file. You'll also see printed out the name of the object's owner and the group.

It's common for people to use "octal notation" when referring to Unix filesystem permissions. In this case, we use three bits to represent the permissions for each category of user, with these three bits then interpreted as a number from 0 to 7 using the formula (read_bit)*4 + (write_bit)*2 + (execute_bit)*1. In the above example the octal representation would be 4+2+0 = 6 for the owner and 4+0+0 = 4 for the group and everyone else, so 644 overall.

Note that to be able to exercise your rights on a file, you also need to be able to access the directory in which it resides. This means having both read and execute permission ("5" or "7" in octal notation) on the directory in question.

You can alter these permissions using the command chmod in conjunction with the octal notation discussed above, so for example

Question.png
[name@server ~]$ chmod 777 name_of_file

means that everyone on the machine 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 owner and group by means of the commands chown and chgrp respectively.

The file permissions discussed above have been available in Unix-like operating systems for decades now but they are very coarse-grained. The whole set of users is divided into just three categories: the owner, the group, and everyone else. What if I want to allow a single user who isn't in my group to read a file? Do I really need to make the file readable by everyone in that case? No. The Compute Canada's national systems offer "access control lists" (ACLs) to enable permissions to be set on a user-by-user basis if desired. The two commands needed to manipulate these extended permissions are

  • getfacl to see the ACL permissions, and
  • setfacl to alter them.

If I want to allow a single person with username smithj to have read and execute permission on the file my_script.py I can achieve this with the command

Question.png
[name@server ~]$ setfacl -m u:smithj:rx my_script.py