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