Fri 18 May 2007 04:25:47 PM UTC, original submission:
The following transcript shows a subtle way to get a disappointing surprise from the find command. I'll explain my complaint after showing you what happens:
=========================================================
nifty > pwd
/nfs/loew
nifty > find /mnt
/mnt
/mnt/cf
/mnt/cf1
nifty > su
Password:
nifty loew # find /mnt
find: cannot get current directory: Permission denied
nifty loew # echo $?
1
nifty loew # cd
nifty ~ # find /mnt
/mnt
/mnt/cf
/mnt/cf1
nifty ~ # exit
=========================================================
Commentary: I'm user 'loew', sitting at my office desk in front of a workstation named 'nifty'. The machine is running linux, and I administer it myself. My home directory is kept down the hall on some central server, and mounted using NFS. The server admin has wisely turned on the root-squash option. That means that user 'root' on a local box (like mine) does not get unlimited access to the nfs partition. In fact, 'root' gets no access at all!
Running find as a non-privileged user in my (NFS-mounted) home directory uses my workstation's own find binary to look at my workstation's internal filesystem and gives the expected results. Fine.
Switching to user 'root' from my home directory puts me in an unusual situation: thanks to NFS security, user 'root' does not have access to the current directory!
My complaint: this unusual situation makes find behave badly. I ask find to look for files in a directory where user 'root' has plenty of access, and find never gets up enough confidence even to try. I can imagine no good reason for this premature failure. Find should try; it would succeed!
Having user 'root' switch to some other directory, like /root, mounted on the local box, restores expected operation for find.
(Find is so important that this issue breaks some important public-domain scripts. E.g., Gentoo Linux's rather central 'revdep-rebuild'.)
Thanks for looking into this.
|