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: Torvald Riegel <triegel at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Florian Weimer <fweimer at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 04 Jun 2013 19:18:21 +0200
- 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> <or61xxi33w dot fsf at livre dot home>
On Sun, 2013-06-02 at 00:49 -0300, Alexandre Oliva wrote:
> 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.
Agreed. We need both a precise definition of the actual guarantees, and
additional rules or conventions that make sense for certain use cases or
programmers with certain skills. But we need the former to also reason
about and explain the latter.