Hi!

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.

Thanks,
Guillem

Hi!

Helmut Grohne mentioned that this was unclear, so let me clarify. The
problematic case is definitely the “native” value, and also an
explicit cpu list not including the arch in the Architecture field.
And the directive on a service file in an arch:all package.

Helmut also proposed that perhaps debhelper could amend the .service
file during installation, and change the value to match the cpu for
the built package. One problem is that there are dpkg architectures
not covered by the supported systemd cpu list, those would need to
drop the directive entirely. The other problem is .service files in
arch:all packages, those would also need to drop the directive.
I'm CCing Niels Thykier for comment on that, because it's not clear
whether debhelper might be considered the right place for this.

Thanks,
Guillem

Hi Guillem,

We concurrently wrote our replies, so this may duplicate your mail a
little.

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.

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.

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 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:

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
    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

Doing so actuall changes .service files and it may make some existing
packages FTBFS. I think this is a useful tradeoff.

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.

Helmut

Only if systemd and the architecture of the service mismatch.
You can e.g. run a i386 service on an amd64 system if systemd is also i386.

If such a check is added, warning or informational would be more
appropriate.

Am 04.06.22 um 00:45 schrieb Michael Biebl:

Btw, you can also install say foreign arm64 binaries on and amd64 system
which will also refuse to run. There is nothing in dpkg which prevents that.

Hi!

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.

See above.

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.

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.

Ack (at build-time).

These would need to be done at "run-time", and they would depend on
whether foreign arches have been enabled, as mentioned above.

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