This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread-, Signal- and Cancellation-safety documentation


On Tue, Jun 04, 2013 at 02:42:59PM +0200, Florian Weimer wrote:
> On 06/02/2013 07:20 PM, Alexandre Oliva wrote:
> >Just like the other calls we mentioned before, when used in situations
> >that assume and require some form of exclusivity that the black box
> >library might break.  Or can you somehow assure the black box library
> >won't call creat or rename or whatever in the dir that was supposed to
> >be exclusively used for something else, but can't equally assure it
> >won't call chdir?!?
> 
> It's easy to create a separate sub-namespace in the file system,
> just by using a specific directory tree for a clearly-defined
> purpose.  For applications like PostgreSQL, messing directly with
> files in their private data directories is like attaching to the
> process with ptrace and changing a few bits.  All bets are off.
> 
> With chdir, umask, signal masks etc., there is just no way to
> introduce a separate namespace in the same process (partly because
> we don't support the clone system call).  This even applies to

The clone syscall is not needed; the unshare syscall will do. I don't
know whether it's part of glibc's interface contract for this to work,
but as far as I can tell, pthread_create and calling unshare in the
new thread is safe and usable with most if not all of the current
unshare flags.

> cooperative, carefully written libraries.  They would probably use
> locking, but there is no single lock they could agree to acquire.

Agreed. The problem is lack of an agreed-upon lock. If that lock were
used as a write-lock around every instance of changing the current
directory and as a read lock around every operation that takes a
filename, that would of course solve the problem in a horrible,
non-concurrent-friendly way.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]