|
|
Permissions IISummary:
Practical ExamplesConfused? :) Well, maybe things will get somewhat clearer with real life examples. FilesA very good example is the 'slocate' package. If you've got that package installed, open a terminal and type: ls -l /usr/bin/updatedb That's the program for updating the '(s)locate' database. You should get something like: -rwxr-xr-x 1 root slocate {...} /usr/bin/updatedb* The first nine characters describe the access rights (the first '-' denotes the file type): Owner | Group | Others = rwx | r-x | r-x Remember: 'r' stands for 'read', 'w' for write, and 'x' for execute. '-' means 'not set' and therefore no right. The order of rights is always 'rwx'. So this string decodes to:
root slocate Owner is root, name of the group is 'slocate'. DirectoriesToo easy so far? Right so. If you try to execute this program as a normal user, you get: slocate: You are not authorized to create a default slocate database1.1 The slocate database is in '/var/lib/slocate'. Let's have a look: ls -l /var/lib/ The rights on this directory look somewhat different:
Since you are not 'root', you can't run 'updatedb': you lack the right to change content in '/var/lib/slocate'. Now you might wonder: "If I don't have access to the slocate database, how comes I can run 'locate' as a normal user? It surely needs access to this database as well1.1 " That's correct. setUID, setGIDIf you run ls -l /usr/bin/locate, you will get something like this: -rwxr-sr-x 1 root slocate {...} /usr/bin/locate* Note the 's' that replaces the 'x' in the column of the group rights. This denotes another important mechanism you might have already heard of earlier: the setUID/setGID mechanism. This mechanism allows users to execute a program with a different User or Group ID. id But if you run 'locate' the 'setGID' ('set Group ID') bit on the 'slocate' executable makes the system think you are a member of the group 'slocate' and thus grants you read access to the database in '/var/lib/slocate'. -rws––x––x 1 root root {...} /usr/X11R6/bin/Xwrapper* The 'Xwrapper' tricks the operating system into thinking that you are 'root' when you start X. The advantage here is that this program allows you to run X and applications on X without having to be root (see Introducing Processes ). Changing PermissionsRemember: Permissions encompass two concepts, ownership and accessibility. Therefore you have two ways of influencing permissions: changing the ownership with the command 'chown' (CHange OWNer) or changing the accessibility with the command 'chmod' (CHange MODus). Changing Ownership With 'chown''chown' is a fairly simple command: chown tom:users test.txt changes the ownership of the file 'test.txt' to owner 'tom' and group 'users'. You can only 'chown' files which you are owning (only 'root' can 'chown' files and directories which are not owned by him). If you just want to change the owner group, use 'chgrp'. You can do this 'recursively' (i.e. for every subdirectory and the files contained therein) by appending the '-R' option: chown -R tom:users docs sets the ownership of all files and directories in the directory 'docs' to owner tom, group users. Changing Accessibility With 'chmod''chmod' is somewhat more difficult to handle. There are three groups: user, groups and others. Take the first letters: u, g, o. And there are three rights: read, write, execute (rwx). 'chmod's syntax goes like this (simplified): chmod {ugo} {+-} {rwx} file Let's say you want to grant (+) the 'read' right (r) to others (o) on the file 'test.txt'. This would be done like this: chmod o+r file.txt You want to rip (-) the owner group (g) of the right to execute (x) the program '/usr/bin/runme': chmod g-x /usr/bin/runme (Most likely you have to be 'root' for this...). chmod go-rwx secure 'chmod' knows some more useful switches, one of which is 'a' (for 'all'). Thus chmod a+r test.txt would grant 'read' rights to the user, the owner group and others. chmod a+x,u+s file will set 'file' to 'setUID root' and executable by everyone. 'chmod' also accepts defining rights by a octal triplet: '4' means 'read', '2' means 'write and '1' 'execute'. If one of these is not granted, its value becomes '0'. A leading fourth cipher may set 'setuid' ('4'), 'setgid' ('2') or the 'sticky bit' ('1'): chmod 750 file sets the owner right on {file} to read + write + execute (4+2+1=7), the group right to read + execute (4+0+1=5), everyone else has no rights at all (0+0+0=0). Is there a difference between those two methods? Yes. The first method sets rights relative, the second absolute. ls -l some.txt Now assume you want to grant 'others' the 'read' right to this file. With the first method, you'd do chmod o+r some.txt and you get -rw-r––r–– (...) some.txt With the second method, you get a different result when applying the same: chmod 444 some.txt The first method leaves the 'write' right of the owner untouched. When using the second method, you always have to specify the absolute permissions for owner, group and others to get the desired result, in this case chmod 644 some.txt It might be better you concentrate on one method to avoid mixups. Popular Cockups With PermissionsHandle permissions with care1.1 They are an integral part of Linux' security concept and may cause you some trouble if applied thoughtlessly. Some examples: chmod -R a-x text. This is a very popular one. You have copied a directory called 'text' from a MS Windows partition. Due to discrepancies in file handling all the files in this directory have the execution bit set (x). "No problem" you think and execute this command. Next time you want to switch into this directory, you just get bash: cd: text: Permission denied You 'su' to the root account and try again: bash: cd: text: Permission denied What the ...? Well, you did not only remove the execution bit from the files in the 'text' directory but also from the directory itself1.1 Which means that no one - even 'root' - is allowed to go into this directory anymore1.1 Just set the execution bit on the directory again: chmod ug+x test If you have a directory structure which contains files you want to strip recursively of the execution bit, but want to prevent 'chmod' from changing the directory bits, too, you will need something like this: find . -type f -exec chmod a-x {} \; This will find all normal text files ('-type f') and run ('-exec') 'chmod a-x' on them. chmod a+rw /dev/.... A popular 'trick' to circumvent collisions with permissions set on device files. Generally one must be very careful in granting rights to the 'others' group. To this group belongs everyone, may he be a legal guest on your box or a filthy intruder1.1 There is usually something wrong a program's configuration if you feel the urge to do this step. If there is absolutely no other way, it is far better to proceed like this: 1) 'su' to 'root'. Run chmod g+rw,o-rwx on the offending device file. The same goes for setUID root programs. If you feel you must set a program 'uid root', proceed like I have outlined in the article on PPP . Notice that changing the permissions on device files is likely to either not work at all or to only have temporary effect, either due to devfs or to PAM. Executing 'chown' before 'chmod'. This is a bad idea because 'chmod' reverts any changes made by 'chown'. 'chmod' sets 'user' and 'group' of the file corresponding to the GID and UID of the person who ran 'chmod'. So run 'chmod' first and then 'chown'1.1 No need to panic now, all this sounds much more complicated than it actually is. And in case you're wondering: yes, all those cockups happened to me, too (and many, many more ;-)). Related Resources:man chmod Revision / Modified: Apr. 21, 2002 Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft. |