[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: new openat-like function: mkdirat

From: James Youngman
Subject: Re: FYI: new openat-like function: mkdirat
Date: Thu, 1 Dec 2005 00:48:02 +0000
User-agent: Mutt/1.5.9i

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

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]