[systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

[František Šumšal]

On 8/26/19 9:43 AM, Ulrich Windl wrote:
>>>> Mantas Mikulenas <grawity at gmail.com> schrieb am 23.08.2019 um 05:55 in
> Nachricht
> <CAPWNY8WRWMv4CS_cRoVp20Q_4aXUUp1CUN-XJWoO4+t3xOmFcQ at mail.gmail.com>:
>> On Thu, Aug 22, 2019, 16:38 Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de>
>> wrote:
>>
>>>>>> systemd tag bot <donotreply-systemd-tag at refi64.com> schrieb am
>>> 22.08.2019
>>> um
>>> 13:56 in Nachricht <20190822115637.1.05C510C92B339AF7 at refi64.com>:
>>>> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
>>> the
>>>> tarball here:
>>>
>>>
>>>>         * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
> to
>>>>           4194304 by default, i.e. the full 22bit range the kernel
>>> allows,
>>>> up
>>>>           from the old 16bit range. This should improve security and
>>>>           robustness, as PID collisions are made less likely (though
>>>
>>> I doubt it's increasing robustness for any existing application as
>>> pid_traditionally was 16 bit. I don't know if some applications try to
>>> sprintf() a pid into a char[6], but if they do, it might cause an
>>> application
>>> failure...
>>>
>>
>>
>> I've been using this value for at least 5 years, and did expect many issues
>> at first, but so far haven't encountered any at all.
>>
>> (I do kind of suspect that if there are any programs affected by this and
>> without source code available, they would be so old that they wouldn't
>> really run on a bleeding-edge distro anyway...)
> 
> Having read some C questions in stackoverflow yesterday, I'm afraid there are
> quite a lot of programmers out there writing code you couldn't even imagine in
> your most terrible nightmares ;-)
> So distribution code may be safe, but some in-house stuff or even "commercial"
> stuff may be horrible:
> (Not to long ago I had a problem that some commercial application only started
> up if the text terminal was wider than 80 characters. Why? The C program called
> "ps" internally, and that in turn truncated output lines depending on the value
> of COLUMNS environment...)
> 
> I think you really don't know what the most terrible imaginable programmer can
> write... ;-)
> 
> Or maybe the infamous Ariane V failure: They reused software they had tested
> before, but the hardware was different ;-)

Frankly, if such software exists and is used somewhere, it should definitely get
fixed or obsoleted. Following your mindset of keeping backward compatibility
even with broken or not future-proof software, we should also revert all changes
regarding the unix timestamp and year 2038 (in general), because changing
the datatype size from 32bit to 64bit _might_ break someone's code.

By the time this change gets to your enterprise distro, it should be pretty well
tested by various distributions close to the upstream. And even if that's not enough,
you an simply override the value back when you package systemd for downstream. From
what I can tell from various reports from our customers in RHEL, bumping
kernel.pid_max to the full 22bit range will be more than a welcome change.

-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190826/40df16fa/attachment.sig>