Surprised at different 'rm -f' operation when root or not root work?
I have just discovered that 'rm -f' (also 'rm -fr') only overrides permissions when run as root. I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission. Strangely the man pages on my system don't seem to document this difference between root and non-root use of rm. For the -f option it just says:- `-f' `--force' Ignore nonexistent files and never prompt the user. Ignore any previous `--interactive' (`-i') option. Which seems to be the non-root case, i.e. it *doesn't* remove a file where you don't have write permission even with '-f'. So where is the 'do it regardless of permissions' action which happens when root uses 'rm -f' documented? Finally, the thing that caused the problem, how do I guarantee that an 'rm -fr' run by a user will be able to delete everything in the specified directory tree? Do I have to do a 'chmod -R +w' first? -- Chris Green
On 19 Jul 15:37, Chris G wrote:
I have just discovered that 'rm -f' (also 'rm -fr') only overrides permissions when run as root.
I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission.
Strangely the man pages on my system don't seem to document this difference between root and non-root use of rm. For the -f option it just says:-
`-f' `--force' Ignore nonexistent files and never prompt the user. Ignore any previous `--interactive' (`-i') option.
Which seems to be the non-root case, i.e. it *doesn't* remove a file where you don't have write permission even with '-f'. So where is the 'do it regardless of permissions' action which happens when root uses 'rm -f' documented?
Finally, the thing that caused the problem, how do I guarantee that an 'rm -fr' run by a user will be able to delete everything in the specified directory tree? Do I have to do a 'chmod -R +w' first?
Can you quickly look at the output of "alias", I'd bet on there being a magic option set in there. -- Brett Parker
On Tue, Jul 19, 2011 at 04:11:47PM +0100, Brett Parker wrote:
On 19 Jul 15:37, Chris G wrote:
I have just discovered that 'rm -f' (also 'rm -fr') only overrides permissions when run as root.
I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission.
Strangely the man pages on my system don't seem to document this difference between root and non-root use of rm. For the -f option it just says:-
`-f' `--force' Ignore nonexistent files and never prompt the user. Ignore any previous `--interactive' (`-i') option.
Which seems to be the non-root case, i.e. it *doesn't* remove a file where you don't have write permission even with '-f'. So where is the 'do it regardless of permissions' action which happens when root uses 'rm -f' documented?
Finally, the thing that caused the problem, how do I guarantee that an 'rm -fr' run by a user will be able to delete everything in the specified directory tree? Do I have to do a 'chmod -R +w' first?
Can you quickly look at the output of "alias", I'd bet on there being a magic option set in there.
If you mean have I got rm aliased then no, I don't have it aliased. chris$ alias alias h='history' alias vi='vile' chris$ -- Chris Green
On 19 Jul 16:23, Chris G wrote:
On Tue, Jul 19, 2011 at 04:11:47PM +0100, Brett Parker wrote:
On 19 Jul 15:37, Chris G wrote:
I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission.
Can you delete the single file? If not, then, erm, dya wanna check what the *directory* permissions are, because if the user hasn't got write to the directory, they can't delete things. Also, please check which rm is being called in each case: as user: which rm as root: which rm If the output of those don't match, that'll be the problem, probably. (certainly I, as a normal user, can happily rm -rf my files and directories)
Finally, the thing that caused the problem, how do I guarantee that an 'rm -fr' run by a user will be able to delete everything in the specified directory tree? Do I have to do a 'chmod -R +w' first?
Can you quickly look at the output of "alias", I'd bet on there being a magic option set in there.
If you mean have I got rm aliased then no, I don't have it aliased.
Fair enough. -- Brett Parker
On Tue, Jul 19, 2011 at 04:41:56PM +0100, Brett Parker wrote:
On 19 Jul 16:23, Chris G wrote:
On Tue, Jul 19, 2011 at 04:11:47PM +0100, Brett Parker wrote:
On 19 Jul 15:37, Chris G wrote:
I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission.
Can you delete the single file? If not, then, erm, dya wanna check what the *directory* permissions are, because if the user hasn't got write to the directory, they can't delete things.
Also, please check which rm is being called in each case: as user: which rm as root: which rm
If the output of those don't match, that'll be the problem, probably.
(certainly I, as a normal user, can happily rm -rf my files and directories)
Partly finger trouble on my part:- I *can* remove read only files that I own using 'rm -f':- chris$ ls -al total 16 drwxr-xr-x 2 chris chris 4096 2011-07-19 17:34 . drwxrwxrwx 29 chris users 12288 2011-07-19 17:33 .. -r--r--r-- 1 chris chris 0 2011-07-19 17:33 xxx -r--r--r-- 1 chris chris 0 2011-07-19 17:33 yyy -r--r--r-- 1 chris chris 0 2011-07-19 17:34 zzz chris$ rm xxx rm: remove write-protected regular empty file `xxx'? n chris$ rm -f xxx chris$ ls -l total 0 -r--r--r-- 1 chris chris 0 2011-07-19 17:33 yyy -r--r--r-- 1 chris chris 0 2011-07-19 17:34 zzz chris$ However, my original problem, 'rm -fr' *doesn't* remove a directory which itself is read only, if I am the user who owns the directory and files but if I get root privileges I can - what happens is as follows:- chris$ ls -ald fred dr-xr-xr-x 2 chris chris 4096 2011-07-19 17:34 fred chris$ rm -fr fred rm: cannot remove `fred/yyy': Permission denied rm: cannot remove `fred/zzz': Permission denied chris$ sudo -s [sudo] password for chris: root$ rm -fr fred root$ ls fred ls: cannot access fred: No such file or directory -- Chris Green
.... and it is the same 'rm':- root$ which rm /bin/rm root$ exit exit chris$ which rm /bin/rm chris$ -- Chris Green
On 19 Jul 17:40, Chris G wrote:
On Tue, Jul 19, 2011 at 04:41:56PM +0100, Brett Parker wrote:
On 19 Jul 16:23, Chris G wrote:
On Tue, Jul 19, 2011 at 04:11:47PM +0100, Brett Parker wrote:
On 19 Jul 15:37, Chris G wrote:
I.e. if I have a file I own that is read only I *can't* delete it if I am the user that owns the file, even using 'rm -f', however if I sudo to root privileges then 'rm -f' will remove the file even if there is no write permission.
Can you delete the single file? If not, then, erm, dya wanna check what the *directory* permissions are, because if the user hasn't got write to the directory, they can't delete things.
Also, please check which rm is being called in each case: as user: which rm as root: which rm
If the output of those don't match, that'll be the problem, probably.
(certainly I, as a normal user, can happily rm -rf my files and directories)
Partly finger trouble on my part:-
I *can* remove read only files that I own using 'rm -f':-
chris$ ls -al total 16 drwxr-xr-x 2 chris chris 4096 2011-07-19 17:34 .
^^^^ looky, write perms on the directory, this is *important*.
drwxrwxrwx 29 chris users 12288 2011-07-19 17:33 .. -r--r--r-- 1 chris chris 0 2011-07-19 17:33 xxx -r--r--r-- 1 chris chris 0 2011-07-19 17:33 yyy -r--r--r-- 1 chris chris 0 2011-07-19 17:34 zzz chris$ rm xxx rm: remove write-protected regular empty file `xxx'? n chris$ rm -f xxx chris$ ls -l total 0 -r--r--r-- 1 chris chris 0 2011-07-19 17:33 yyy -r--r--r-- 1 chris chris 0 2011-07-19 17:34 zzz chris$
However, my original problem, 'rm -fr' *doesn't* remove a directory which itself is read only, if I am the user who owns the directory and files but if I get root privileges I can - what happens is as follows:-
chris$ ls -ald fred dr-xr-xr-x 2 chris chris 4096 2011-07-19 17:34 fred
^^^ directory not got write perms, therefore you can't delete the files *in* it, if it can't delete the files in it, it won't remove the directory (for obvious raisens). The directories need write permission, the files don't. You can simply do: find fred -type d -exec chmod u+w {} + Then you'll probably find that it "just works".
chris$ rm -fr fred rm: cannot remove `fred/yyy': Permission denied rm: cannot remove `fred/zzz': Permission denied chris$ sudo -s [sudo] password for chris: root$ rm -fr fred root$ ls fred ls: cannot access fred: No such file or directory
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. This is *NOT* something special in rm, this is filesystem level. Ergo, it wouldn't be documented in the rm man or info pages. Hope that clears up why you *can't* do that rm, and that this is *not* a weird behaviour on the part of rm, but a filesystem permissions level not at all weird, maybe slightly unexpected side effect of the directory not having write support. Thanks, -- Brett Parker
On Wed, Jul 20, 2011 at 10:15:55AM +0100, Brett Parker wrote:
However, my original problem, 'rm -fr' *doesn't* remove a directory which itself is read only, if I am the user who owns the directory and files but if I get root privileges I can - what happens is as follows:-
chris$ ls -ald fred dr-xr-xr-x 2 chris chris 4096 2011-07-19 17:34 fred ^^^ directory not got write perms, therefore you can't delete the files *in* it, if it can't delete the files in it, it won't remove the directory (for obvious raisens).
The directories need write permission, the files don't.
Yes, I realised the reason for it no working, but was surprised that 'rm -fr' didn't override it.
You can simply do: find fred -type d -exec chmod u+w {} +
I can simply do 'chmod -R +w *', no need for the find. :-)
chris$ rm -fr fred rm: cannot remove `fred/yyy': Permission denied rm: cannot remove `fred/zzz': Permission denied chris$ sudo -s [sudo] password for chris: root$ rm -fr fred root$ ls fred ls: cannot access fred: No such file or directory
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!
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. -- Chris Green
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, -- Brett Parker
participants (2)
-
Brett Parker -
Chris G