Bug#869719: udev-234 doesn't execute when udev architecture != systemd architecture

[Jarek Kamiński]

On Fri, Sep 01, 2017 at 02:25:42PM -0300, Felipe Sateler wrote:
> On Tue, Aug 22, 2017 at 7:31 AM, Michael Biebl <biebl at debian.org> wrote:

Sorry for late response, I was on holiday.

>>> I was running an uncommon configuration of 64-bit systemd and 32-bit
>>> udev (strange omission I'm going to fix right now). It was running fine
>>> until udev-234, when udev started being killed with SIGSYS. Setting
>>> SystemCallArchitectures= (instead of native) in systemd-udevd.service
>>> made udev working again.
>>>
>>> While I understand the root cause was my error, udev is such critical it
>>> would be great it was more robust :-)  Please consider setting
>>> SystemCallArchitectures to the architecture of the udev package,
>>> tightening the dependencies, or at least some sanity check during
>>> installation.
>>
>> This can unfortunately not be expressed via package dependencies afaik
>> and dropping SystemCallArchitectures= doesn't seem like a good idea. I
>> suspect this was added upstream for a good reason
>> I'm also not convinced if it's worth complicating the maintainers
>> scripts for such an exotic case.
> 
> Well, udev can run arbitrary programs via RUN commands, is it right to
> assume that those will always be native?

Agreed. Indeed, even broadening SystemCallArchitectures won't help here,
as I learned when my system didn't boot because of some of the helpers
being other architecture.

As I see it, SystemCallArchitectures is a nice hardening measure, but
nothing more than that. It doesn't help with any immediate security
threats and might provide some benefit only in case of hypothetical
attacks. Therefore, my preferred solution would be to drop it completely
from the udev unit file.

Another option is to state clearly the RUN interface works only for
native applications, but then if the system is multi-arch, there is no
way of knowing if some non-native executable can't be called directly or
indirectly. Such requirement can have an impact on other foreign
packages innocently being called from udev rules. It can be also pretty
hard to debug and have an impact on booting the system.

Third option is to set SystemCallArchitectures to all architectures
enabled in dpkg, but it sounds quite complex and removes all potential
benefits from setting it in the first place (because on multi-arch
systems that will typically equal to all architectures supported by the
kernel anyway).


For the record, the (short) upstream discussion is here:
https://github.com/systemd/systemd/pull/5283#pullrequestreview-22863442,
I'm adding the reviewer to CC:.


-- 
pozdr(); // Jarek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170903/0af03af1/attachment-0002.sig>