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: Rich Felker <dalias at aerifal dot cx>
- To: Alexandre Oliva <aoliva at redhat dot com>
- 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, 2 Jun 2013 10:20:28 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <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, Jun 02, 2013 at 12:49:23AM -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 ;-)
Yes, I forgot to mention suid. As for exploits, they would have to be
kernel-compromise exploits, not plain root exploits, since there is no
root to exploit. :-)
> > 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.
There's still a big difference. With other filesystem operations like
rename, write, etc. you can use them meaningfully in a multithreaded
program as long as it's clear that you're not stepping on other
modules' data. In other words, they have both correct usage and
incorrect usage. However, chdir has only incorrect usage. Assuming you
use libraries that are "black boxes" (i.e. you don't have any
guarantees about their implementations, only their interfaces) chdir
can NEVER be called safely except at startup or between fork and exec,
because it breaks all usage of relative pathnames in other functions.
Rich