I´ve got a little problem. I´ve added a script (info.sh) to the /etc/skel directory and changed the permissions to 500. When I create a new user the file is copied and ownership is changed to the new user. The user should be able to execute the file, but not be able to change it. Even so the permissions are correct, I still can change the file as the new user. The system tells me that I´m about to change a read only file, but on exit it writes the changes to the file. Any ideas regarding this behaviour?
Many editors (not “the system”) behave like this. They ask the owner if (s)he realy intends to overwrite the file. And of course the owner has the saying. When the owner then says “yes”, the editor does the chmod u+w, writes the file and then restores with chmod u-w.
After all making your own file read-only for the owner is only a protection against your own faulty handling. The user could of course change the pemission to writable before edditing easily, hus this is no security breach, but just helpfull.
It is not clear to me what you want to achieve by setting this. As said it may warn the user extra when (s)he changes the file, but the user is the owner, thus (s)he is in charge and is responsible. (s)he can make the file writebale after first login, just to make it easier to change it next year.
To achieve this is easy enough. There are hundreds of executable files on the system that can not be changed by the user. They reside in places like /bin, /sbin, /usr/bin, etc.
A good place for an executable that is local to a system (or group of local systems) is /usr/local/bin. Create it when not available. The nice thing is, that it is by default part of the PATH environment variable. Which means that the user only has to type (using the file name you choose):
info.sh
Of course make it owned by root:root and give it permission rwxr-xr-x.
And my personal opnion, give it a better name without a dot (.) in it. Have you ever seen a dot (.) in system program to be executed by users?
Added bonus is that this executable is automaticaly available to all users without having to change things in /etc/skel.
Actually editor probably does not overwrite content in place, it creates temporary file and renames it. And that requires just write permissions to containing directory and is not affected to permissions on file itself.
That is another possibility. In any case the user is warned that the command he gives might be contrary to his/her intentions. And the action is taken (or not) as the user confirms (or not).
And indeed, many people have no correct understanding about what write permission on a directory means.
Thanks everyone for the informations. I haven´t considered that point of views. I´m still learning linux and trying to get a better grasp, especially with my upcoming LPIC-Certification. I believe I have to rethink my understanding of file permissions. Thanks for the input again.
Hint. Specialy the meaning of permissions on directories are important to understand.
A directory is no more then a table of file names in one column and an i-node address in a second column. So read access to a directory means that you can read the table. Write acces that you can write to the table: creating new files, removing files, renaming files. That is all independent from the permisions of the file itself. Thus even when a file has --------- as permissions, you can remove/delete it whe you have w permission to the directory.
The x permission for a directory means that you have access to the inodes themselves. The inodes contain much information about the file. Amongst them the owner uid and guid, the permissions, the time stamps, etc.
Compare:
henk@boven:~/test> ls -l bestanden
totaal 324
-rw-r--r-- 1 henk wij 3964 10 mei 2013 ASH.html
-rw-r--r-- 1 henk wij 796 10 mei 2013 index.html
-rw-r--r-- 1 henk wij 157943 10 mei 2013 verf.gif
-rw-r--r-- 1 henk wij 157943 10 mei 2013 verf.jpeg
-rw-r--r-- 1 henk wij 122 10 mei 2013 WARNING_README.txt
henk@boven:~/test> chmod a-x bestanden/
henk@boven:~/test> ls -ld bestanden
drw-r--r-- 2 henk wij 4096 13 jul 2013 bestanden
henk@boven:~/test> ls -l bestanden
ls: kan geen toegang krijgen tot bestanden/verf.jpeg: Toegang geweigerd
ls: kan geen toegang krijgen tot bestanden/index.html: Toegang geweigerd
ls: kan geen toegang krijgen tot bestanden/ASH.html: Toegang geweigerd
ls: kan geen toegang krijgen tot bestanden/WARNING_README.txt: Toegang geweigerd
ls: kan geen toegang krijgen tot bestanden/verf.gif: Toegang geweigerd
totaal 0
-????????? ? ? ? ? ? ASH.html
-????????? ? ? ? ? ? index.html
-????????? ? ? ? ? ? verf.gif
-????????? ? ? ? ? ? verf.jpeg
-????????? ? ? ? ? ? WARNING_README.txt
henk@boven:~/test>
You see that in the second case the x permission on bestanden is off. You can see what is there (r permission), but all inode data is unobtainable.