LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Linux Answers > Security
User Name
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
What we are interested in is the cryptic 'r's 'w's and 'x's on the left side. You may already know that these are the permissions of the respective files. So what do they mean?

'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
In this example we can see that the first three are 'rwx' which means the owner of the file can read, write or execute it. The group can read and write (rw-), and everybody else is limited to viewing the file (r--). In this particular example we can see that the file's owner is 'bulliver', and the file's group is 'web'.

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
Not much to this, right? Let's move on to something complicated.

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     |
--------------------------------------------------------------------------------------
So you just add the appropriate mode numbers to arrive at your desired permission. It may be easier to consider each entity as a single digit, in the usual order (owner group other). As always, this theory is best understand with some examples. Let's imagine a hypothetical file named 'myscript'. 'myscript' is a shell script that we are writing that performs a useful function. When we first create it we don't want others to mess around with it, so we set some restrictive permissions while writing it:

Code:
[joe@localhost]$ chmod 600 myscript
[joe@localhost]$ ls -l myscript
-rw-------    1 joe user           192 Feb  6 14:55 myscript
Now let us imagine that we need some help with our script, so we make it available to our programmer friend, who just happens to belong to a group called 'web'. We need to change the group, and change the group permissions:

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
Our script is now almost done, and we want to test it. We need it to be executable:

Code:
[joe@localhost]$ chmod 770 myscript
[joe@localhost]$ ls -l myscript
-rwxrwx---    1 joe web           192 Feb  6 14:55 myscript
Our script is now perfect. We are going to make the script available for all users to run, and we want them to be able to see our handywork so we'll let everybody read and execute it. We don't want users changing it however, so they don't get write permission:

Code:
[joe@localhost]$ chmod 775 myscript
[joe@localhost]$ ls -l myscript
-rwxrwxr-x    1 joe web           192 Feb  6 14:55 myscript
This should give you a good working knowledge of absolute mode. Just remember that to get your permission, add the appropriate mode numbers.

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 4755 myscript
this would execute 'myscript' with the permissions of the files owner(such as root, if the file is own by root),and not the normal user executing 'myscript'. As you can imagine, this should be used sparingly if at all, as it defeats the normal permission structure,and can lead to security issues.

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 2755 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
As you can see pretty much any combination is valid as long as you follow the '[entity][operator][permissions]' formula.

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 1755 /tmp  prefix a '1' to set the sticky bit
Setting the sticky bit on files was 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!

by Azmeen on Wed, 2003-08-20 20:40
This article can be improved by touching on the chattr command as well

by mlp68 on Wed, 2003-09-17 00:13
I see that the comments have dried up some time ago...

One suggestion, one comment: You could add some sentences about umask and what it does.

The comment is about this suid- "myscript" thing. I know it's just to show the recipe, but it suggests that it's ok to have such a script, while it's not. ("'myscript' is a shell script that we are writing that performs a useful function.") The target here are people new to Linux, and they may not know better. Fundamentally, such a script cannot be made unexploitable (path issues. temp file issues. IFS issues. Remaining race conditions that cannot be fixed. And so on and so on.) Because of that, the Linux kernel will not honor the suid bit for scripts, so on linux one is safe. But Solaris has no such inhibitions, for example.

Just my 5cts on this peripheral issue. Nice article!

mlp

by king_nothingzzz on Fri, 2004-01-16 01:48
Quote:
Originally posted by mlp68
The comment is about this suid- "myscript" thing. I know it's just to show the recipe, but it suggests that it's ok to have such a script, while it's not. ("'myscript' is a shell script that we are writing that performs a useful function.") The target here are people new to Linux, and they may not know better. Fundamentally, such a script cannot be made unexploitable (path issues. temp file issues. IFS issues. Remaining race conditions that cannot be fixed. And so on and so on.) Because of that, the Linux kernel will not honor the suid bit for scripts, so on linux one is safe.
Firstly, i think that this is a very informative article. I really appreciate the authors help towards people who are new to Linux. This covers up pretty much everything that one needs to know about file permissions for basic usage.

Secondly, i think all that bashing from mlp68 was totally unwanted. As far as i know, no newbie will even think about 'myscript', they will concentrate on how to go ahead setting file permissions. I'm saying this from a newbie's point of view. I'm not a Linux 'Guru', but certainly not a newbie.

I know how a newbie (with considerable IQ) will think while reading the article and what he/she concludes from it.

I mean, how many newbies do you know who know anything about path issues, temp file issues, IFS issue etc??

Once again, i say that this is a very good article

Cheers

King Nothing

by mlp68 on Fri, 2004-01-16 18:14
I wouldn't call my comment "bashing" - it's just a friendly comment.

M.

by king_nothingzzz on Sat, 2004-01-17 01:25
Maybe *Bashing* was an inappropriate word, but it did look like that to me.
No offense, but still all those things that you said were not necessary

King Nothing

by bulliver on Fri, 2004-04-30 01:22
I didn't consider it bashing, in fact I'm still trying to figure out what the hell mlp68 is talking about. It was just a random example, and i used the 'myscript' thing because I wanted to fit chmod + x into the example. Wouldn't work with an image or mp3 in the example would it .

BTW I just wanted to say that I did not add the parts about suid or the sticky bit, they were added by whoever proofread the article prior to posting it here.

Cheers folks....

by mlp68 on Fri, 2004-04-30 13:55
Hi Bulliver,

first off, sorry if others perceived my comment as bashing. It's a great and well-written article. I was just referring to that paragraph


Quote:
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 4755 myscript


this would execute 'myscript' with the permissions of the files owner(such as root, if the file is own by root),and not the normal user executing 'myscript'. As you can imagine, this should be used sparingly if at all, as it defeats the normal permission structure,and can lead to security issues.
You say the right warning words, but since the linux kernel doesn't honor the SUID bit for scripts at all (because of the security flaws I listed, and some more), this wouldn't work. But worse, other flavors of Unix don't have those inhibitions about suid scripts, and that's where it could become dangerous (that's why I said a novice could take away from here that it is ok, while it's not). You can have a suid (or guid) executable, but not a script.

Have a look at http://www.phrack.org/phrack/47/P47-05 (question 10) which I just googled. It has a nice summary and explanation of the 4 easiest exploits. (There are more.)

Again, I didn't mean to diminish your great article, just point out this thing. Sorry if it came across the wrong way.

mlp

by thrice on Fri, 2004-05-14 00:46
i think its a great article. i've never really understood how absolute modes worked because the explanations i've read ramble on about bits and such, but your illustration made it verry simple. thanks again

by bulliver on Fri, 2004-05-14 01:38
Thanks man, means a lot...

by Qucho on Sat, 2004-05-15 03:04
Quote:
i think its a great article. i've never really understood how absolute modes worked because the explanations i've read ramble on about bits and such, but your illustration made it verry simple. thanks again
Hell YES !!!! this was in my mind all the time I was reading it. For the first time I get to understand that thingy.

And by it, I also inherited knowledge about WHAT in ALL heavens, my fstab should have for my winXP partitions and the DARN umask attribute !!!!!

This newbie has gotten alot of benefit from the article. THANKS !!

What I didnt see explained there, and still want to know (might be out of scope) is: How do I add a exacuatable to a specific group. (I.E. I want 'cdburn' to be executed by users in group 'cdwrite')


  



All times are GMT -5. The time now is 12:46 AM.

Main Menu
Advertisement

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration