Dmargolis: /* Further reading. . . */

2017-08-11T18:29:49Z

Ccn admin: 38 revisions

2014-01-16T03:10:15Z

38 revisions

New page

Information contained within this entry is heavily based on Perifect's article
[http://www.perlfect.com/articles/chmod.shtml Understanding UNIX and chmod].

OSX: There are some differences in the way osx handles permissions from other UNIX's.
However, the following should be accurate for all lab members on the Hoffman2 cluster.

=Introduction=
There are three levels of ownership and three levels of permission that you need to know.

[[File:Unix-Permission.gif]]

==Ownership==
Every file in UNIX has an owner user and an owner group.
Only the owner of a file can change its permissions (Unless you are an Admin)

====Owner====
Owner = you, the user. UNIX identifies each user by a User ID (UID) and the username (or login) such as 'nick' and 'bobby'.

====Group====
Groups = your buddies. A user may belong to one or more groups of users. The concept of groups serves the purpose of assigning sets of privileges for a given resource and sharing them among many users that need to have them. (perhaps because they are all members of a project working team and they all need access to some common project files) So, on my system user 'nick' and user 'bobby' both belong to the group 'perllab'. This way, they can have some shared privileges over the files for this lab's projects. User 'nick' needs the files to contribute to the project, and user 'bobby' needs them to contribute to nick's work.

:To Find out what group you are in, use [[UNIX_Permissions#id]].

====Other====
Others = the random guys. They represent anybody on the system.

==Permissions==
Security for your files and directories.

===Files===
Every file on the system has associated with it a set of permissions. Permissions tell UNIX what can be done with that file and by whom. There are three things you can (or can't) do with a given file:

*read it, gain access to looking into file
*write (modify) it and change things in the file
*execute it, to run as a program

Unix permissions specify which of the above operations can be performed for any ownership relation with respect to the file. In simpler terms, what can the owner do, what can the owner group do, and what can everybody else do with the file. For any given ownership relation, we need three bits to specify access permissions: the first to denote read (r) access, the second to denote (w) access and the third to denote execute (x) access. We have three ownership relations: 'owner', 'group' and 'all' so we need a triplet for each, resulting in nine bits. Each bit can be set or clear. (not set) We mark a set bit by it's corresponding operation letter (r, w or x) and a clear bit by a dash (-) and put them all on a row. An example might be rwxr-xr-x.What this means is that the owner can do anything with the file, but group owners and the rest of the world can only read or execute it. Usually in UNIX there is also another bit that precedes this 9-bit pattern. You do not need to know about it, at least for the time being.

===Directories===
Another interesting thing to note is that lib/ which is a directory has permissions, too. Permissions take a different meaning for directories. Here's what they mean:

*read determines if a user can view the directory's contents, i.e. do ls in it.
*write determines if a user can create new files or delete file in the directory. (Note here that this essentially means that a user with write access to a directory can delete files in the directory even if he/she doesn't have write permissions for the file! So be careful with this.)
*execute determines if the user can cd into the directory.

: To Find out the permission, use [[UNIX_Permissions#ls]]

=Tools=
These Unix Tools will help you out when you want to modify permissions.

===ls===
If you try ls -l on the command prompt you will get something like the following:
[nick@thekla src]$ ls -l
-rwxr-xr-x 1 nick users 382 Jan 19 11:49 bscoped.pl
drwxr-xr-x 3 nick users 1024 Jan 19 11:19 lib/
-rwxr-xr-x 1 nick users 1874 Jan 19 10:23 socktest.pl

The first column here shows the permission bit pattern for each file. The third column shows the owner, and the fourth column shows the owner group. By the time, the information provided by ls -l should be enough for you to figure out what each user of the system can do with any of the files in the directory.

[[File:Unix-Permission.png]]

===chmod===
To set/modify a file's permissions you need to use the chmod program. Of course, only the owner of a file may use chmod to alter a file's permissions. chmod has the following syntax:
chmod [options] mode file(s)
The 'mode' part specifies the new permissions for the file(s) that follow as arguments. A mode specifies which user's permissions should be changed, and afterwards which access types should be changed. Let's say for example:
chmod a-x socktest.pl
This means that the execute bit should be cleared (-) for all users. (owner, group and the rest of the world) The permissions start with a letter specifying what users should be affected by the change, this might be any of the following:
*u the owner user
*g the owner group
*o others (neither u, nor g)
*a all users (u, g, & o)

This is followed by a change instruction which consists of a +(set bit) or -(clear bit) and the letter corresponding to the bit that should be changed.

Let's see some examples:
$ ls -l socktest.pl
-rwxr-xr-x 1 nick users 1874 Jan 19 10:23 socktest.pl*

Now let's remove the executable bit for all users
$ chmod a-x socktest.pl
$ ls -l socktest.pl
-rw-r--r-- 1 nick users 1874 Jan 19 10:23 socktest.pl
Then set the write bit for the owner group
$ chmod g+w socktest.pl
$ ls -l socktest.pl
-rw-rw-r-- 1 nick users 1874 Jan 19 10:23 socktest.pl
And add the ex>ecutable permission for both the user owner and the <g>roup owner
$ chmod ug+x socktest.pl
$ ls -l socktest.pl
-rwxrwxr-- 1 nick users 1874 Jan 19 10:23 socktest.pl*
Finally, remove both the write bit and the executable bit for both the user and group owners
$ chmod ug-wx socktest.pl
$ ls -l socktest.pl
-r--r--r-- 1 nick users 1874 Jan 19 10:23 socktest.pl
====Strange numbers...====
You might have encountered things like chmod 755 somefile and of course you will be wondering what this is. The thing is, that you can change the entire permission pattern of a file in one go using one number like the one in this example. Every mode has a corresponding code number, and as we shall see there is a very simple way to figure out what number corresponds to any mode.

Every one of the three digits on the mode number corresponds to one of the three permission triplets. (u, g and o) Every permission bit in a triplet corresponds to a value: 4 for r, 2 for w, 1 for x. If the permission bit you add this value to the number of the permission triplet. If it is cleared, then you add nothing. (Some of you might notice that in fact, the number for a triplet is the octal value corresponding to the three-bit pattern - if you don't know what an octal value is, it doesn't really matter, just follow the intstructions) So if a file has rwxr-xr-x permissions we do the following calculation:
Triplet for u: rwx => 4 + 2 + 1 = 7
Triplet for g: r-x => 4 + 0 + 1 = 5
Tripler for o: r-x => 4 + 0 + 1 = 5
Which makes : 755

So, 755 is a terse way to say 'I don't mind if other people read or run this file, but only I should be able to modify it' and 777 means 'everyone has full access to this file'

===chgrp===
As the name may imply to the astute, this utility changes the group of a file or directory. A user may only change a files group to a group for which they are a member. chgrp syntax is:
$ chgrp <groupname> <file or directory name>

An example case might look like this:
Suzie is a member of both groups perllab and rubylab. She's collaborating with Que, a member of rubylab. Unfortunately, the files she wishes to share have a group owner of perllab and Que cannot read them. Fortunately, since Suzie is also a member of rubylab she can remedy this easily with chgrp.
$ chgrp rubylab project_directory

She might also need to change the directories permissions to ensure that the group owner can use the files
$ chmod g+rwX project_directory

If Suzie wanted to ensure that all files contained in project_directory, she'd execute the following recursive commands (which should look familiar given the chmod examples above.)
$ chgrp -R rubylab project_directory
$ chmod -R g+rwX project_directory

===umask===
Each user has a default set of permissions which apply to all files created by that user, unless the software explicitly sets something else. This is often called the umask, after the command used to change it. It is either inherited from the login process, or set in the .bash_profile file which configures an individual account, or it can be run manually.

On the Hoffman2 server, this is set to only allow read/write permissions to the user, while group and other's are given permission to read, but not write to new files.

If you wish to more lax permissions, you must change your umask in your .bash_profile or manually each time you wish to change them. Setting the umask is not immediately intuitive. As the name implies, the argument to umask are the bits you do not want set.

An examples:
*To make it so all new files give all permissions to the owner, read permission to the group, and no permissions to others
$ umask 027

We have not masked any bits by passing the 0 in the first slot, we have masked (removed) the write permission for all group members by passing the '2' to the second slot, and we've masked all possible bits for others by passing '7' to the third slot.

Here are a few more examples that cover the most common cases:
*To allow the user and the group to read, write, or execute new files
$ umask 007
*To allow only the user to read or write or execute new files (highest privacy)
$ umask 077

===newgrp===
There is also a handy utility called newgrp that eases permission problems. The newgrp utility changes the default group ownership for new files. For example,
$ id foo
uid=8122(foo) gid=4004(staff) groups=4004(staff),1901(webadmin)

The user 'foo' is a member of the webadmin and the staff groups. Her gid is currently 'staff'. This means that any new file she creates will belong to the staff group.

But when foo wishes to work with web files, it would make things much easier for all of the other members of the webadmin group if the files she created had a group ownership of webadmin. It would also be much easier for foo if she did not have to worry about doing a
$ chgrp webadmin newfile.html

For every file she creates. This is where newgrp comes in. By issueing the following command before she begins to work, she can ensure that all newly created files are owned by the webadmin group.

$ newgrp webadmin

That's it! She may also wish to retain the more restrictive permissions of read only group access by default but in the case of doing collaborative work change that to a group read/write permissions. By combining newgrp with umask this is a very easy task.

$ umask 007

This needs to be executed after newgrp to take effect. Issueing the newgrp command sets your environment back to its defaults.

===id===
You can find out the full list of groups that a user belongs to with the following command

$ id bobby

Of course, 'bobby' should be replaced with the name of the user you're interested in. It's a very common task to check which groups two users are in so you may assign that common group to a file and allow both of them to read/write/edit the file. We'll find out how to do just that shortly.

=Further reading. . .=
*The original [http://www.perlfect.com/articles/chmod.shtml article]
*It is a good idea to take a look at the manual page for chmod (you can do this with man chmod) where you will find out more details and options on how to set permissions, plus some other kinds of permissions that we avoided to discuss here for the sake of simplicity and clarity.
*The first 1/2 of this [http://www.dartmouth.edu/~rc/help/faq/permissions.html Dartmouth Tutorial] is good
*An exhaustively complete tutorial for the [http://www.catcode.com/teachmod/ chmod] utility including examples, mini quizzes, and more
*The venerable Sultans of Tech, O'Reilly, have also written up a [http://www.onlamp.com/pub/a/bsd/2000/09/06/FreeBSD_Basics.html tutorial] for us

← Older revision		Revision as of 18:29, 11 August 2017
Line 176:		Line 176:
	*The original [http://www.perlfect.com/articles/chmod.shtml article]		*The original [http://www.perlfect.com/articles/chmod.shtml article]
	*It is a good idea to take a look at the manual page for chmod (you can do this with man chmod) where you will find out more details and options on how to set permissions, plus some other kinds of permissions that we avoided to discuss here for the sake of simplicity and clarity.		*It is a good idea to take a look at the manual page for chmod (you can do this with man chmod) where you will find out more details and options on how to set permissions, plus some other kinds of permissions that we avoided to discuss here for the sake of simplicity and clarity.
	*The first 1/2 of this [http://www.dartmouth.edu/~rc/help/faq/permissions.html Dartmouth Tutorial] is good
	*An exhaustively complete tutorial for the [http://www.catcode.com/teachmod/ chmod] utility including examples, mini quizzes, and more		*An exhaustively complete tutorial for the [http://www.catcode.com/teachmod/ chmod] utility including examples, mini quizzes, and more
	*The venerable Sultans of Tech, O'Reilly, have also written up a [http://www.onlamp.com/pub/a/bsd/2000/09/06/FreeBSD_Basics.html tutorial] for us		*The venerable Sultans of Tech, O'Reilly, have also written up a [http://www.onlamp.com/pub/a/bsd/2000/09/06/FreeBSD_Basics.html tutorial] for us

UNIX Permissions - Revision history

Dmargolis: /* Further reading. . . */

Ccn admin: 38 revisions