linux-kernel - Re: [Linux] Linux PID algorithm is BRAINDEAD!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOCW0DhWKeOh75BGQtMAif7WVZAs5JXw=vgu99sm3egrimTE4g@mail.gmail.com>
Date:	Mon, 12 Oct 2015 13:49:59 -0400
From:	Dave Goel <deego3@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>, Dave Goel <deego3@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Linux] Linux PID algorithm is BRAINDEAD!

Ted,

Thanks for your patience with me.

I thought I had this down, and I thought that the only real
problem is *immediate* re-use and the race conditions it causes
and that for all other cases, scripts can find a way to work
around things. But:

But truly, your example stumps me atm.

Completely understood your point that the "real" solution is to
properly use trap in all scripts. What that also entails in practice is
working with every debian package and program .. .  If A calls B
that calls C which then calls D, and they are all programs
written in different languages, some of which don't even allow
arguments, etc.  But, indeed, that's not the kernel's "problem."

In the meanwhile, if deep inside D, I am generating files that A
needs to be aware of (again, A through D are in different
languages, with their own broken utilities), I can always add
additional information and make it unique.  I can use random
strings to make it unique enough, or if I need deterministic, I
can add pid + start time (jiffies of the proc) + linux start
time (btime from /proc/stat) to make it unique enough.  If I
truly have a unique PID, I never have to worry about any of this,
I guess.

OTOH, I guess if one has to write cleaner/other meta scripts without
proper traps, the cleaner can simply check if linux's PID counter
is too close to the current PID, and if so, refrain from drastic
actions. For the latter, I wonder if there's a way to
get "current PID counter."

Thanks again,
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/