On Wed, Nov 30, 2005 at 09:53:53PM +0100, Jim Meyering wrote: > I haven't looked too closely at find, but its -execdir predicate > makes me think having exec*at functions would be useful, too.
Only slightly. POSIX requires that -exec should happen with the working directory the same as it was when find was started. On the other hand, the -execdir action does the exec from the same directory as the files to be processed (the point of -execdir is that it makes it less likely that an attacker can exploit a race condition in the executed program). Since both choices need to be usable, at least one of them will always need to do an fchdir(). If execvpat() were provided, one of them would then use execvp() and the other would use execvpat(). However, the only additional performance cost is one fchdir() per -exec* call. I can't see a security consideration that would lead us to prefer execvpat(). However, there is a theoretical future world where find spawns a thread to process file subtrees which live on independently-seekable media (i.e. separate spindles). Doing that though requires the use of some kind of external library that knows enough about how block devices work to figure out if two devices can be accessed simultaneously without performance penalty. That's not so high on the priority list, though a similar invention might be useful for optimising fsck pass numbers. > But can glibc provide those without kernel support? Well, I suspect that glibc could just do fchdir() after the fork (not before, because otherwise the environment for pthread_atfork() handlers would be wrong). I suppose that execvpat() would need to define what happens if the set-user-id user does not have search permissions on the specified directory. All in all, such a function seems to me to be mildly attractive because it logically fleshes out the set of available functions (along with chownat, lchownat, linkat, symlinkat, and unlinkat). In fact there are many syscalls in there. Perhaps a cleaner design might be somehow to have a thread-local working directory and an fchdir() syscall that can't fail. Thinking about this again though, that would mean that somebody (glibc or the kernel) would need to retain a record of whether this thread had done a change of its thread-local working directory since the last call to chdir() or fchdir(). Ugh, yuck. No, in summary, I think it's quite likely that the inconvenience of implementing and maintaining an execvpat() function outweighs its utility. James. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
