Bug#982456: lintian: systemd SystemCallArchitectures directive incompatible with M-A:foreign
Hi!
On Wed, 2021-02-10 at 15:18:31 +0100, Helmut Grohne wrote:
> Control: tags -1 + moreinfo
> On Wed, Feb 10, 2021 at 01:42:59PM +0100, Guillem Jover wrote:
> > The systemd unit file directive SystemCallArchitectures is
> > incompatible with Multi-Arch:foreign markings in a package, as that
> > means once you install such foreign package, systemd will refuse to let
> > it run.
> >
> > Please tag this as an error.
>
> I think this is an interesting aspect, but less clear than you picture
> it.
>
> If my foo:amd64 package ships a .service file with
> SystemCallArchitectures=x86-64 and calls a binary from the same package,
> then M-A:foreign can very well make sense. Thus far, this case is not
> practically relevant, because no upstream .service file works this way.
Having thought about this more, I think even the arch-specific value
is still potentially problematic, as things this service depends on,
calls directly or links against might change under its feet, and
end up calling programs for the "wrong" arch.
> If my foo:amd64 package ships a .service with
> SystemCallArchitectures=native, then this is a problem, because native
> here refers to the architecture of systemd and since systemd is
> M-A:foreign, that can be any architecture. So we'd have to restrict this
> error being signalled explicitly to the value native.
See above.
> Unfortunately, that's the most likely value for upstreams to put there.
>
> That puts us in a difficult situation. It's essentially Multi-Arch
> versus hardening. What we'd want is "it just works".
I guess perhaps an option could be to generate overrides that check
for the architectures enabled in dpkg and generate appropriate
SystemCallArchitectures directives for services.
> I think we can do better with a little bit of support from debhelper.
> debhelper already ships a dh_installsystemd that specially handles
> .service units. How about extending it? Let me propose some pseudo-code:
It's not clear to me whether you mean that these would be done at
package build time or installation time. I think some parts, make
sense at build time, because those are properties of the package, and
others at run-time, because those are properties of the system.
> if the .service unit contains SystemCallArchitectures:
> if the relevant binary package is Architecture: all:
> if the package is Multi-Arch: foreign:
> die with an error
Ack (at build-time).
> else:
> Let systemd_arch be the systemd name of the relevant package
> architecture.
> if the value of SystemCallArchitectures is native:
> Replace it with systemd_arch.
> if the value of SystemCallArchitectures is not systemd_arch:
> die with an error
These would need to be done at "run-time", and they would depend on
whether foreign arches have been enabled, as mentioned above.
> In this setting, packages would likely not have to change as debhelper
> would take care of the fixups. So I wonder whether a lintian tag is
> really necessary (assuming that debhelper can be changed). Tagging the
> bug moreinfo for now.
I still think a lintian tag makes sense, regardless of the level, as
that gives visibility over the problem, and covers things that might
not be using debhelper?
Thanks,
Guillem
Reply to: