Re: rm bug?

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 6,  1:17am, Thomas Klausner wrote:
} 
} While debugging a test failure in the backup tool bup, I noticed the
} following difference between NetBSD's and Linux' rm(1):
} 
} Linux
} 
} # mkdir -p a/b
} # chmod 000 a/b
} # rm -rf a
} # ls -l a
} ls: cannot access a: No such file or directory
} 
} NetBSD
} 
} # mkdir -p a/b
} # chmod 000 a/b
} # rm -rf a
} rm: a/b: Permission denied
} rm: a: Directory not empty
} # chmod +x a/b 
} # rm -rf a     
} rm: a/b: Permission denied
} rm: a: Directory not empty
} # chmod -x a/b
} # chmod +r a/b
} # rm -rf a
} # ls -l a
} ls: a: No such file or directory
} 
} I can understand a bit why NetBSD's rm does not remove a directory
} into which it cannot descend. However, I don't understand why allowing
} it to descend is not enough (notice the failure after the "chmod +x"),
} or why giving read permissions on the directory (INSTEAD of execute
} permissions) is sufficient for rm(1) to delete it.

     The simple explanation is, if you can't read the directory,
you can't find out what is in it in order to iterate over the
contents in order to empty the directory.  Remember that "x" only
allows you to enter the directory.  If you know the name of the
item you want, then you can access it.  But, if you want to get a
listing of what is in a directory, then you need "r".

} I think this is a bug. If there's a reason NetBSD's rm(1) doesn't
} match the Linux behaviour, it should match it at least after the
} "chmod +x".

     I suspect that NetBSD's behaviour is the traditional behaviour.
Although, it is possible that the behaviour was modified by kauth.

}-- End of excerpt from Thomas Klausner