This is the mail archive of the libc-help@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: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?


My apologies.  I use a somewhat old but more stable free software
distribution and the safety annotations do not seem to be in my Libc
documentation.  Now my problem is much smaller than what I thought it
was.

Okay, so I'm going to make a wiki entry like:

Improvements to GLibc to better support sandboxing.

After a fork in a multithreaded program a number of things are messed
up and so only AC-safe (async-signal-safe) functions can be relied
upon with certainty.  To better support sandboxing, GLibc needs to
clarify and possible improve the async-signal-safety of a number of
functions.

GLibc needs to document pthread_sigmask, prctl and unshare and note
them as AS-safe. They are simple system call wrappers and are most
likely AS-safe.

setgroups is important to sandbox and restrict the privileges of a
process. However, it has to do some complicated setxid
synchronization. As such, it may be AS-unsafe and might deadlock
programs that use it after a fork in a multithreaded program.  I'm not
sure if the setxid synchronization is safe after a fork from a
multithreaded program or not.

And I'll need to find a way to contact Google Chrome, systemd, LXC and
Docker.  I feel fine with emailing the mailing lists of systemd, LXC
and Docker but I've had trouble getting into contact with Chrome
developers before.  Can someone else contact them for me?

I'll also need editor approval for my account of StevenStewartGallus
and am CC'ing a copy of this reply to libc-alpha so I can add the wiki
entry.

Thank you,
Steven Stewart-Gallus


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