UNIX for Dummies Questions & Answers

Hi,
I have noticed that on my Linux box there is a nice feature which make it impossible for specified member (owner, group or other) to have an given access if a member from which we would expect it more don't have that access.

So it is impossible to read file by all if others have set read bit but owner or group doesn't have.

But I haven't found that the above feature is guaranteed by any standard. So is it on which really I can rely on?

By the way: I have observed that even experienced users has sometimes problems when asked if a given structure of permissions will give a specified member access to such-and-such operations on the file and on the contents of the file. In the fact that subject isn't really clearly explained even in the books in which I was looked for it.

So to systematize it, what I have found/observed:
- if you want to run native Linux application then x permission is enough to execute it. But it is not the case if you want to run shell (sh, bash, ...) script - then you need to add r permission. As far as I know that it is caused by the fact that shell uses system call read() to read from file,

- if you haven't permission to read directory then it is impossible for you to list a contents of that directory. But still it is possible to read, write and execute files (if they have neccessary permissions); otherwise Linux permissions are not inherited, so if subdirectory has a read permission then it is possible to list files which are in it.

- if you haven't permission to execute directory then it is impossible to read inode of that directory (it is arbitrary arranged that it has completely different meaning from x permission for usual files - it has nothing in common with real executing). Basically it means that you can't cd to it. If a directory "dir" hasn't x permission and there is a file "textfile" in that directory you will not have access to that file. But if you have a subdirectory "subdir" in "dir" then permissions of "subdir" are on his own. For example if it has rwx permissions it is possible to cd to that directory and then successfully edit and write to file.

- if you haven't w permission to a directory then it is possible for you to write to it. But it is possible for you to write to files in that directory.

Please inform me if something from which I have written above is not true - part of that is from my observation. I would be grateful for other examples where one could be confused about permissions and how it affect system file.

Thanks in advance for responses.

Not quite sure what you're saying -- that if a file's owner doesn't have read access, but world has access, the owner can't read it? That sort of thing?

I see that on BSD too, and I think I remember it happening on Solaris, so I think it's fairly consistent... It picks the set of permissions to check against first and then is either pass/fail, it doesn't check another set if the first fails.

Are you referring to the set UID or Guid bit? (Sometimes referred to as the "sticky" bit?) This bit is to run or set the owner or group as the actual entity running the executable or otherwise accessing the file; there is no known way (to me anyway without the use of intervening shell or program code) to set permissions on a file any other way than SUID/User/SGID/group/other.

man page: chmod

Addendum: remember that "directories" are just another type of file. So, each and every file can have individual permissions. Example: Directory "users" has 700 permissions set. (user-all (r/w/x), group - none ; others-none). File "myfile" within the "users" directory has "777" permissions- everyone can do all (r/w/x). So, if you are not the owner of "users"; you CANNOT do an ls (listing) on the users directory (you can't list the files in it). BUT, you CAN read, write OR execute the /users/myfile, since everyone has full permissions on that file.

Understand? (This is quite commonly used for anonymous FTP transfers so that you can only see and access the files that you transferred up to the target server.)

Again, remember that directories are just another sort of file. Not a true "directory"; just a parent-child pointer for organization.

No. I just want to say that if I have a file which has permissions set to 007 then it will be impossible to write, read or execute this file by any user - all owner, group and others will have access denied to that file. If you want to make access to read, write and execute that file to others then it has to have permissions 777. So you can set some permissions for others and don't give that permissions to owner/group but simply it won't work. Similarly if you set some permissions for group but don't give that permission to owner.

But again - what I have said above is based on my observation and I haven't found it guaranteed in any standard, so I don't know if really I can rely on that feature. But such solution seems to be desirable - I can't see any logic in permission like 007, 050 or 077.

Of course directories still are files, but they are treated by the system in something special way. For example it isn't possible to view and edit directory with vi or emacs. So it is responsibility of a system for make it possible to list a contents of directory, not yours. It is explicitly stated that directory includes i-numbers and again a system is in charge of knowing how to dealt with it, not you. And execute permission is treated in other way for directories than for normal files.