On 20 Jul 10:51, Chris G wrote:
On Wed, Jul 20, 2011 at 10:15:55AM +0100, Brett Parker wrote:
Yes, that's because root has a mostly get out of jail free card, permissions checks generally go "ah, it's root, sod it, yeah - you've got permission to do that", where as a normal user is bound by the usual filesystem rules.
Which seems 'wrong' to me, OK, I realise "that's how it is" but it still feels wrong for root to be able to remove files in a read-only directory that is owned by root. In fact a simple 'rm' as root removes files in a read-only directory without any warning! It makes directory permissions pretty irrelevant to root!
You can set some magic flags to make it so that root behaves the same way, but that's still kernel/filesystem level, not utilities level. Directory permissions *are* pretty irrelevant to root. Lets face facts, you have root, you can su to any other user anyways. This is why one shouldn't host anything that they feel is sensitive or important on boxes where they don't trust root. If you don't trust the root user, though, then you probably shouldn't be accessing the box in the first place. Simples.
This is *NOT* something special in rm, this is filesystem level. Ergo, it wouldn't be documented in the rm man or info pages.
So I can't read the man page for a command and trust that it actually does what it says? Normally I'd expect a notes section that mentions exceptions at least, how else can one find out what a command does in any particular situation? It used to be that the man pages were almost definitive but no more apparently.
You can expect that it'll behave as the man page says, within the confines of normal unix permissions structures.
Just wait till you get apparmor/selinux in the way too, then all bets are off, entirely. Basically, man pages are not going to tell you what's going to happen if you do a standard operation that isn't permitted by the underlying OS, that's not their job, their job is to tell you what happens when the permissions are on their side - the give away from rm was Permission Denied, which is perfectly fair.
If every manpage for utilities that play in the filesystem had notes explaining every possible thing that might happen, the man pages would soon become useless, and trying to keep that same chunk of information in sync across the hundreds of utilities would be a complete nightmare.
Also, the reason that I suggest using find rather than a recursive chmod is simple - it was *only* changing the permissions of directories, *and* it wouldn't hit the command line length limit in the case of there being hundreds of files/directories to expand from *. find is by far one of my favourite tools, and has got me out of more jams than I care to remember. Mixed with xargs it is part of the usual sysadmin toolbox and I'm yet to find a sysadmin worth their salt that doesn't know both of those tools rather well. (along with sed or perl).
Cheers,