This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Florian Weimer <fweimer at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sun, 02 Jun 2013 00:49:23 -0300
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb> <ora9nrh1cz dot fsf at livre dot home> <51A328F0 dot 5020003 at redhat dot com> <ora9ncqlg4 dot fsf at livre dot home> <51A86363 dot 2000900 at redhat dot com> <orip1yq3ek dot fsf at livre dot home> <20130601025934 dot GJ20323 at brightrain dot aerifal dot cx>
On May 31, 2013, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, May 31, 2013 at 05:51:15PM -0300, Alexandre Oliva wrote:
>> Huh? How could anyone ensure it has exclusive access to a filename
>> that's about to be renamed, or overwritten by a rename?
> If the directory has a 255-character random name and is located in a
> non-readable directory owned by root on a system where no process has
> retained root, then you can be quite certain that only the process(es)
> which have the name of the directory or a live file descriptor for it
> can perform a rename in it.
Yeah, I know, but you forgot the âno suid root executableâ and âno
root-me exploitsâ constraints ;-)
> Extreme examples aside, if an application is working in a working
> directory that (by contract/convention) belongs to it, and which has
> the right permissions so that other users cannot mess with it, and the
> application has documented that the user running the application
> cannot mess with the contents of this directory while the application
> is running without invoking UB, then you have a reasonable real-world
> situation where exclusivity is "guaranteed".
I'd argue the same goes for chdir. Just like the âdon't mess with my
exclusive dirâ technique you wrote about above, nothing prevents other
threads in the same process from messing with it. It's a matter of
setting a convention and abiding by it.
Of course there's room for an unaudited library call somewhere to
introduce an unwanted use of chdir, but by the same argument, there's
room for an unaudited library call to mess with the directory that was
supposed to be exclusively used for other purposes. Neither should be
used in the multi-threaded program that relies on either exclusivity.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer