Messages in this thread | | | Date | Thu, 17 Jun 1999 10:19:04 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Odd filesystem permission handling |
| |
Logged in as user "mharris" and in my home dir, I had a dir called "down" owned by root.root with perms 755.
This dir had files in it.
As "mharris" I tried to chown the dir to mharris.mharris, and I got permission denied. I then tried "rm -rf down/" also as mharris, and it successfully let me remove the directory.
So how is this that I can remove a dir, and all of it's files, owned by root, without permission, but I can't modify the permissions on the files? I dont understand.
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.
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 HOWTO that comes with RedHat? I'd really like to fully understand all the permissions settings, sticky bit, etc... and differences on files and dirs with these perms. Also, SUID and SGID dirs, etc..
Any pointers to clear consise explanations would be great.
Thanks.
-- Mike A. Harris Linux advocate GNU advocate Computer Consultant Open Source advocate
Tea, Earl Grey, Hot...
- 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/
| |