When the program exits, any path changes will be lost anyway. Your prompt will still come back to your shell's current working directory since environment changes do not flow upstream.

I recommend using chdir to change to the root directory for sake of portability, but you could make it any other directory the account can access.

Below is some example code. I can run this as root in root's home directory without any errors. It changes to my non-root account, changes to the root ('/', not to be confused with '/root') directory, searches a directory my non--root account can access (and actually owns in this case, but that's not important), and File::Find returns to '/' when it's done.

use File::Find;
$< = $> = 500;
sub w { print $_ . "\n" }
chdir q(/);
find( \&w, qw( /home/chris/Pictures ) );
[download]

There's no reason for File::Find not to return to the directory from which it started. There's also no reason to have it return to a directory where the user account under which it is operating has no privileges. No code that might be executed afterward would have rights to that directory either anyway.

Thanks - that makes a lot of sense. I hadn't considered that changing directory to root or elsewhere is harmless since it doesn't outlast the routine.

The root directory will tend to be readable by all users by default anyway. A directory that's by default world-readable is the ideal place to not have permission errors upon reading.

Many daemon programs actually change directory to '/' as one of the first things they do. Some others are written to have a specific directory set up just for a chroot jail.

I think that's perfectly fine attitude for a subroutine; to have as few side effects as possible.