| The
PermitMe page: User
& Group
creation - modification & file permissions. Paragraphs in this page are: Overview User & Group creation - modification More advanced permission options A finetuning example |
||||||||||||||||||
Overview Let us remember a paragraph from the HintMe page: Files beginning with a dot are considered "hidden". Q: It reminds me of hidden system read only etc. A: Hidden is just symbolic. It really means "stand out of my way" when listing. "Hidden" "system" "read only" and "archive" files don't exist the way the average user is used to. These attribures are good in single user operating systems, as a last measure for protection in an environment that you are always a "root". In all unixes, the ability of a user to manipulate a file is depended on the file's permissions (read write execute) as well as ownership (user:group). Lets get started. Always call the manual page of every command you see here i.e. man groupadd We are going to use commands here the simplest possible way. |
||||||||||||||||||
User & Group creation - modification Login as root. lets find out whether the group users exists or not: cat /etc/group | grep users If exists then something like: users::100: will be shown. If not, let's make it: groupadd users Now lets make a user named "guest" Simply type: useradd -g users guest we also chose the user's primary group. mkdir /home/guest we made the homedir. chown -R guest:users /home/guest we configured the ownership. useradd needs a special command to automatically make the homedir. useradd may also choose the group "users" by default, if not specified. If making the homedir by hand as root, always configure the ownership. now create a password: passwd guest a password will be asked twice, or three times if very simple. Now we do exactly the same for a user "friend" useradd -g users friend mkdir /home/friend chown -R friend:users /home/friend passwd friend Notice that both homes belong to the same group. Now we are going to make a user "test" that will NOT belong to the group "users" groupadd test useradd -g test test mkdir /home/test chown -R test:test /home/test passwd test Now let's make a full listing:
The ownerships are obvious. d stands for directory. rwx stands for read,write,execute. For files, rwx is obvious. For directories: r means list their contents w means create, modify, remove files inside them x means enter (cd) inside them. Q: Why so many symbols? A: Look at the table:
/home/friend is rwx to friend, r x to group users, r x to others. now let's: remove friend's reading permission to others remove guest's execute permission to others remove all test's permission to others chmod o-r friend chmod o-x guest chmod o-rx test now lets see the difference:
Now, friend and guest will not be affected since they obey the "group" permissions which didn't change but: test cannot ls /home/friend ! test cannot cd /home/guest ! because when test was created, a group other than "users" was assigned. Also: guest and friend cannot see test's home BUT if root or test gives group ownership of /home/test to users: chgrp users test then:
now friend and guest can enter/read test's home. chmod works also with octal numbers:
/home/friend permissions are 7 5 1 /home/guest permissions are 7 5 4 /home/test permissions are 7 5 0 read carefully the man page of chmod. there are other features, too. |
||||||||||||||||||
More advanced permission options Chmod uses 2 more options, not described by POSIX, to help finetuning permissions. 1) the setuid bit: Using this bit in a binary, the executor of the binary ingerits the owner's permissions. issue: ls -l /usr/bin | grep rws and you will find all binaries in /usr that once ran by the common user, will have the permissions to alter the system. For example, passwd with the setuid bit will allow the user to change only his/her password and update the /etc/shadow. If the setuid bit was not set, then only root could change any password! Of course, since root is the owner of the global directories, only he/she may alter the setuid bit. 2) the sticky bit: The sticky bit permits general write options but grants deleting permission only to the user that owns the file/dir and the directory it lies into. It is often used to global write directories like /tmp in order to maintain a decent security level. This ability can be extended to shared directories for users. |
||||||||||||||||||
A finetuning example We login as the most regular user i.e. micro and create a shared dir in /home as root: su -c 'mkdir /home/shared ; chown micro:users /home/shared' (password will be asked) Then we create some directories as micro: cd /home/shared mkdir documents setup pub chmod go-rx setup ; chmod a+w pub ; chmod o+t pub touch pub/NEWS ; chmod g+w pub/NEWS documents: accessible to all users but writable for micro. setup: accessible only by micro. Sources may lie here. pub: writable by all but noone will be able to remove other's files except micro. NEWS inside pub: writable by all that belong to group users but removable by micro only. Beware: NEWS will be modified by the last person that saves the file, therefore only one user may succesfully edit it at a time. UNIX does not generally support the "lock" method while accessing common files. While this seems "clumsy" at first glance, it gives much power considering multiusage options inside the system. A user can be logged mutiple times locally and remotely (shells and GUIs) without "harassing" the operational state of the central system or his/her own patience (e.g. error file not editable etc.etc. you know ... this is not the case in Unix). If by mistake the same file is opened twice with a modern app inside a modern desktop, when the file is changed and saved in one app, the other will inform us of this event and will then ask for actions. |