[Semibug] SystemD is literally the kitchen sink of Linux ; Linux starting to feel more and more alien as the years go on

[Kyle Willett]

Thanks Ron for that education.  Like I said I hope I didn't offend
anyone with my mailing list post.

I have to wonder how real world a problem :
"As such, PIDs do not allow another process to maintain a private,
stable reference on a process."
is?

If OpenBSD hasn't yet found a reason to address this how bad can it
be?  They are normally the first OS to address each security issue.
First to PIE, first with Kernel layout reordering at boot, etc.

That is interesting that FreeBSD adopted a similar method as did
Illumos.  I will read those links tonight.

-Kyle

On 12/6/23, Ron / BCLUG <admin at bclug.ca> wrote:
> Kyle Willett wrote on 2023-12-06 13:59:
>
>> Now to quote the article: "Most internal process tracking is now
>> using PIDFDs rather than PIDs when running on a supported kernel."
>>
>> What the heck is a PIDFD instead of a PID.
>
>  From
> https://kernel-recipes.org/en/2019/talks/pidfds-process-file-descriptors-on-linux/
>
>> Due to how pid allocation works the kernel is free to recycle PIDs
>> once a process has been reaped.
>
> Makes sense.
>
>> As such, PIDs do not allow another process to maintain a private,
>> stable reference on a process.
>
> Uh-oh. That could be bad.
>
>
>> On systems under pressure it is thus possible that a PID is recycled
>> without other (non-parent) processes being aware of it. This becomes
>> rather problematic when (non-parent) processes are in charge of
>> managing other processes as is the case for system managers or
>> userspace implementations of OOM killers.
>
> Sounds like a real-world problem that's being addressed. Not that I've
> encountered it. (That I'm *aware* of - would I even know?)
>
>
>
>> All Unix users know what a PID is it is universal but Linux has to be
>> different.
>
> On page 6 of the embedded slide show at the link above, there's a
> section called "Prior Art", and in that list are:
>
> * Illumos: similar userspace tools
> * OpenBSD, NetBSD: no private, stable process handles
> * FreeBSD: procdesc:pdfork(), pdgetpid(), pdkill()
> * Linux: forkfd(), CLONE_FD
>
>
> So, looks like FreeBSD and Illumos have similar mechanisms?
>
> With OpenBSD & NetBSD, good luck, I guess?
>
>
> At least, that's how I'm reading it; could well be wrong.
>
>
> TL;DR - it appears that PIDFDs are addressing a real-world problem
>
> _______________________________________________
> Semibug mailing list
> Semibug at lists.nycbug.org
> https://lists.nycbug.org:8443/mailman/listinfo/semibug
>