Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> My kneejerk reaction is that it's not worth making this change.  The
> attack in question will work against almost any program that is
> operated in an insecure directory, including the "chmod" program
> itself.  It'd be a real pain to work around this problem in all
> applications, one at a time, and it's not at all clear to me that it's
> even doable in general.
>
> I suggest simply warning users that if you let bad guys modify your
> directories, you're asking for trouble.  Which is certainly true in
> any event.
>
> That being said, it would be an easy security improvement if mkdir -m
> would use lchmod rather than chmod, on platforms where lchmod is
> available.  There may be several other programs where this would be
> advisable as well, and similarly for lchown versus chown.

I would be more interested in that approach if I knew that
lchmod support were coming to Linux sometime soon.  I see that
NetBSD, OpenBSD, HPUX (but not Solaris) provide it.

This reminds me of Solaris' very nice openat, fdopendir, fstatat
functions[1].  They too provide useful functionality that can't be
emulated cleanly, yet Linux doesn't provide the necessary syscalls.
I suppose a weak replacement function is the `right' way to go --
then, as for openat, redirect complaints to the Linux kernel folks.

Jim

----------
[1] I'm not interested in attribute-related semantics of openat, but
rather in the fd-relative-open--related semantics.  openat et.al. are
very useful in any code that would otherwise have to change to a new
directory and then later return to the initial working directory.
No code that tries to do that with chdir (or even with open/fchdir) can
be truly robust, but it's easy with openat and company.  The problem
is that sometimes it is impossible to return, even with open/fchdir.
With openat, you define away the problem by making it unnecessary to
change the current working directory.