On Wed, 12.07.17 09:51, Florian Weimer (f...@deneb.enyo.de) wrote: > * Lennart Poettering: > > > On Tue, 11.07.17 21:26, Florian Weimer (f...@deneb.enyo.de) wrote: > > > >> * Lennart Poettering: > >> > >> > Apparently, this regressed between this version and > >> > glibc-2.24-9.fc25.x86_64 hence. > >> > >> Yes, I backported the fork cache removal to Fedora 25. There is no > >> longer a good way to main such a cache in userspace because glibc > >> cannot intercept anymore all the ways that can change the PID of the > >> current process because the kernel interfaces for process management > >> are incredibly rich these days. > > > > Please be more specific here. What is this all about? > > We got many bug reports over the years about sandboxes and other heavy > users of namespaces and clone that the glibc PID cache got out of > sync, both in child and parent (!) processes.
have any links? > > What triggered this specifically? is this about docker? docker is > > written in golang anyway, iirc, which doesn't bother with linking to > > libc anyway? > > It needs glibc for access to the host and user databases. can you elaborate? I fail to see any relationship between unshare()/fork()/getpid() and NSS? > > Is this a glibc upstream choice primarily? Were the regressions this > > causes considered? > > I raised the problem of applications calling getpid frequently and > named OpenSSL as an example. Link? > > I mean, the getpid() checking code is not only in use in systemd, but > > in various other bits, in particular PulseAudio, where I started > > adding these checks for a good reason. It sounds pretty strange to me > > to just regress all that... > > Fork detection using getpid is not reliable. It gives false negatives > in the case of double-forks, where the process can be different but > the PID is the same due to reuse. Considering that this use case is > broken, I don't think it's worthwhile to jump through hoops to support > code which is fundamentally broken anyway. Uh, that's a bit non-chalant, no? Yes, the UNIX PID concept is awfully designed, but if you argue on that level, you#d have to remove kill(), and half of the other syscalls that take a PID from glibc too... The primary intention of checking the PID in our calls is to filter out cases where people assume they can use our context objects across fork()s: a clean, early error code is a ton better than memory corruption. And I am pretty sure the usecase is very valid... And yes, even if checking getpid() misses some theoretical corner cases, pthread_atfork() or whatever else you propose will miss others too, and is much uglier codewise, introduces deps, yadda yadda... Gah, this is all so ugly. I understand systemd is not a program you are particularly interested in, but making us chase around your regressions is just mean... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel