> 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/