[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-
From: |
Jim Meyering |
Subject: |
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039) |
Date: |
Fri, 15 Apr 2005 21:41:56 +0200 |
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.