Re: rm bug?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Linux

> # mkdir -p a/b
> # chmod 000 a/b
> # rm -rf a
[no messages, works]

> # mkdir -p a/b
> # chmod 000 a/b
> # rm -rf a
> rm: a/b: Permission denied
> rm: a: Directory not empty

If this is being run as root, as the # prompt implies, IMO this is a
bug (unless the directory is on an NFS server, in which case it depends
on the mount options and possibly the server-side config).  rm running
as root should blow past the permissions checks.

If it is not being run as root, this strikes me as entirely correct; in
that case, I think it's the Linux version that is buggy.

> # chmod +x a/b 
> # rm -rf a     
> rm: a/b: Permission denied
> rm: a: Directory not empty

Arguably correct.  Without read access to a/b, rm can't tell whether
there's anything in it.  Arguably it should try rmdir on it anyway, in
case it's empty, but I don't consider it indefensible for it to not do
that.

> # chmod -x a/b
> # chmod +r a/b
> # rm -rf a
> # ls -l a
> ls: a: No such file or directory

This makes sense.  rm can read a/b, but there's nothing there so
there's no need for search (+x) access.  If there were something in
a/b, read access would not be enough.

% mkdir -p a/b
% touch a/b/x
% chmod 0 a/b
% chmod +r a/b
% rm -rf a
rm: a/b/x: Operation not permitted
rm: a/b: Directory not empty
rm: a: Directory not empty

(I also get this if I make a/b mode 666, rw-rw-rw-.)  If I try this as
root, it removes things just fine (as I'd expect).

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B