Messages in this thread | | | Date | Thu, 17 Jun 1999 16:00:15 +0000 | From | Johan Myréen <> | Subject | Re: Odd filesystem permission handling |
| |
"Mike A. Harris" wrote:
> Is this standard UNIX behaviour? If so, sorry for the > disruption. The chmod manpage is horrible at explaining in plain > english what all of the permission bits are, and how they work. > My understanding is that root owned files and dirs, with no "w" > priv assigned to other users are only removeable by root. It > appears thought that the files inherit the permissions for "w" > from the owner of the dir that they are in.
> Can someone point me to a very well written explanation of all > UNIX/Linux file permissions, that isn't the chmod manpage or a
They are quite simple and logical, actually. If you have write permission to a file, you can edit it (change the contents). Removing and creating files in a directory is "editing" the directory, i.e. the permissions of the directory (not the file itself) apply. An exception to this rule is that if a directory has the sticky bit set, removing files is restricted to files you own yourself. This can be useful on publicly writable tmp directories.
> Is this a bug, or is it normal behaviour. If so, how can I chown > files other than switching to root? Also, where is the logic in > allowing a user to remove directories owned by root that are in a > subdir owned by another user.
The logic is that you have full control of your own directory. If there are several (hard) links to the file, you aren't even deleting the file, just removing one of the references.
You can't chown files as a regular user. In some (older) versions of Unix you can give away a file you own, but that possibility was removed when disk quotas were introduced.
Johan Myreen jem@iki.fi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |