This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- From: Zack Weinberg <zackw at panix dot com>
- To: navid Rahimi <rahimi dot nv at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 10 Sep 2015 17:50:27 -0400
- Subject: Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- Authentication-results: sourceware.org; auth=none
- References: <55F19819 dot 3010601 at gmail dot com> <ACDB9D4B-30B6-46C1-9286-5F03594CEACC at panix dot com> <CAOUBrm3oeUVDM-q4VFP08gjEkD2UFaz0Xfq1oGBW+m76rDRu+A at mail dot gmail dot com>
On Thu, Sep 10, 2015 at 5:38 PM, navid Rahimi <rahimi.nv@gmail.com> wrote:
> On Thu, Sep 10, 2015 at 7:32 PM, Zack Weinberg <zackw@panix.com> wrote:
>> Why is a TOCTOU race acceptable and/or unavoidable? Also, why is a check using the real rather than the effective credentials correct here?
>
> Because of nature of lock in unix (being advisory) I think there is no
> way to lock file and prevent TOCTOU, even if we had lock mechanism ,
> it is cumbersome (and almost impossible) to design in correctly.
It just occurred to me that you could open() the file in the parent
and then use fexecve() in the child. If that worked correctly it
would address both my concerns and Phil's. However, fexecve is faked
on top of /proc, which means there are all sorts of ways it might not
work 100% reliably, and for correctness you would need an open mode
that may not actually exist (O_EXEC, I guess it would be called).
All in all I am inclined to say leave things as they are. Nobody uses
posix_spawn if they can help it, anyway :)
zw