Home Forums Reviews Tutorials Articles Register Search Today's Posts Mark Forums Read User Name Remember Me? Password

Notices



By bulliver at 2003-07-12 23:36 One of the most confusing issues for Windows defector is that of file permissions. Home-user Windows systems have no concept of file ownership, which depending on your situation, can be a good or bad thing. You need to keep in mind that Linux is at heart a Unix system, and Unix is built to support multiple users. Even on a home computer permissions are a useful feature which allow you to block sensitive files from being edited, or even read by non-authorized people.



To further illustrate this point, consider your old Windows box. You might have spent hours or days getting your preferences and settings just right, only to find that the next time you sit down at the computer somebody has changed the widget colours to an ungodly lemon yellow, and changed the system time to GMT when you live in New York. Another example: You spend all weekend putting the finishing touches on a report for your boss, but unfortunately it is lost forever because your child has just discovered the joy of "delete". Oops.



These examples may be a bit extreme, but suffice it to say that ensuring your files don't get 'accidently' deleted, or viewed by the wrong eyes provides a great deal of comfort.



overview



In a nutshell, there are three types of permissions, and three entities that receive these permissions. As a quick example type 'ls -l' in a directory. Any directory. You should see something like this:



Code: -rwxr-xr-x 1 bulliver web 664 Feb 9 02:28 ip2name.pl -rw-r--r-- 1 bulliver web 1704 Feb 1 07:29 letter.dvi -rw-r--r-- 1 bulliver web 1185 Feb 5 19:16 letter.latex -rwxrwxrwx 1 bulliver web 192 Feb 14:55 darren_says



'r'

'read' permission. This allows you to read, view, or otherwise open the file depending on context.



'w'

'write' permission. This allows you to edit or delete the file.



'x'

'execute' permission. This allows you to run the file as a program.



So who recieves these permissions? We have three entities: owner, group, and other.



owner

Typically the owner is the person who creates the file. The majority of system files are owned by root, ensuring that mortal users cannot erase or edit important system settings.



group

Groups create a way to share files between users, for example, a team of designers who are working together on a project. Groups may also be used to allow access to certain devices, such as CDROMs or printers to regular users.



other

As the name implies, this permission applies to everybody else. We need to pay particular attention to this permission because if it is set to read or write then anybody can view, edit, or delete the file.



Looking back to our 'ls -l' example you can see that there are 10 slots in the listing. The first slot is usually just a dash (-) which tells us it is a regular file. Sometimes it is a 'd' for directory, 'l' for link, or 'c' for character device. We don't need to worry about that right now. The other 9 slots are our three permissions for our three entities. The first three are for the owner, then group, then other. Perhaps an example:



Code: -rwxrw-r-- 1 bulliver web 192 Feb 6 14:55 darren_says



ownership and groups :: chown and chgrp



To change the owner of a file, we use the chown command. The format is 'chown [new owner] file'. To change the file's group, we use the chgrp command. The format is the same 'chgrp [new group] file'. To save some typing we can change both in one shot using the dot notation: 'chown [new owner].[new group] file'. Let's have some examples:



Code: [root@localhost]$ ls -l anyfile -rw-rw-r-- 1 bulliver web 192 Feb 6 14:55 anyfile [root@localhost]$ chown root anyfile [root@localhost]$ ls -l anyfile -rw-rw-r-- 1 root web 192 Feb 6 14:55 anyfile [root@localhost]$ chgrp bozo anyfile [root@localhost]$ ls -l anyfile -rw-rw-r-- 1 root bozo 192 Feb 6 14:55 anyfile [root@localhost]$ chown bulliver.web anyfile [root@localhost]$ ls -l anyfile -rw-rw-r-- 1 bulliver web 192 Feb 6 14:55 anyfile



permissions and chmod



A file's permissions are also known as its 'mode' to gurus and Linux geeks, so to change them we use the 'chmod' command (change mode). There are two ways of specifying the new permissions using chmod: symbolic and absolute.



absolute mode

Because you are dying with suspense, I will just tell you that absolute mode is the one with the numbers. You can use simple arithmetic to arrive at the permission you are looking for. Consider:



Code: ------------------------------------------------------------------------------------- | owner | group | everyone | ------------------------------------------------------------------------------------- | read | write | execute | read | write | execute | read | write | execute | ------------------------------------------------------------------------------------- | 400 | 200 | 100 | 40 | 20 | 10 | 4 | 2 | 1 | --------------------------------------------------------------------------------------



Code: [joe@localhost]$ chmod 600 myscript [joe@localhost]$ ls -l myscript -rw------- 1 joe user 192 Feb 6 14:55 myscript



Code: [joe@localhost]$ chgrp web myscript [joe@localhost]$ chmod 660 myscript [joe@localhost]$ ls -l myscript -rw-rw---- 1 joe web 192 Feb 6 14:55 myscript



Code: [joe@localhost]$ chmod 770 myscript [joe@localhost]$ ls -l myscript -rwxrwx--- 1 joe web 192 Feb 6 14:55 myscript



Code: [joe@localhost]$ chmod 775 myscript [joe@localhost]$ ls -l myscript -rwxrwxr-x 1 joe web 192 Feb 6 14:55 myscript



SETUID



Normally, when a program is run it inherits all the rights/restrictions of the user that executed it. if a user can't read /var/log/messages, then neither can any program/script executed by that user. There is a way around this, we again use the chmod command but add a '4' at the beginning of the permission string, example:

Code: chmod 4 755 myscript



SETGID



The setgid bit works the same way, except instead of applying to the files owner, it is applied to the files group setting. the chmod command is used again prefixing a '2' as the first digit.



Code: chmod 2 755 myscript relative mode



As the name implies, relative mode only changes permissions relative to the current permissions. That is, you can add or remove permissions from the existing ones. The format is pretty much the same as absolute mode: 'chmod [new_mode] file'. It is only the mode that is different.



We have three parts, which for lack of better terms, are '[entity][operator][permissions]'. The entities describe who gets the permissions. They are: 'u': user, the file's owner

'g': group, the file's group

'o': other, everybody else

'a': all, all three together

The operators decide whether we add, remove, or emulate absolute mode (ie: describe permissions from scratch). They are:

'+' : add permissions

'-': remove permissions

'=': emulate absolute mode

The permissions we have seen already, they are nothing new: 'r' : read permission

'w': write permission

'x': execute permission

There are actually quite a few more options available, but they should not be necessary for casual use. If you are really curious I direct you to 'man chmod'. Perhaps some more examples are in order.



Code: chmod a+x filename # adds execute permissions to all chmod u+x filename # adds execute permissions to the file's owner chmod ug+w filename # adds write permissions to the file's owner and group chmod o-rwx filename # removes read, write, and execute permissions from other chmod a=rx filename # creates a 555 permission from scratch



THE STICKY BIT



Linux directory access permissions say that if a user has write permissions on a directory, they can rename or remove files there,even if the files don't belong to them.

When the owner of the directory sets the sticky bit, renames/removals are only allowed by the files owner, the directories owner and the root user.



Code: chmod +t /tmp to set the sticky bit chmod -t /tmp to remove the sticky bit or chmod 1 755 /tmp prefix a '1' to set the sticky bit once used to force a copy of the file to stay in swap space, in an attempt to speed execution the next time the file was used. This hasn't been used in quite some time, due to advances in memory management. You can still set the sticky bit on a file, but the kernel will just ignore it.



Well, I hope this has helped you get a handle on Linux file permissions. It's really not as hard as it might seem. That's all for now, happy chmoding to you!









All times are GMT -5. The time now is 04:02 AM .

