This in particular makes sure that we normalize the user name and update
it in the PAM session, once we acquire it. This means that if you have a
user with name "a" and alias "b", and the user logs in as "b" they end
up properly with "a" as user name set, as intended by the PAM gods.
Moreover, if you have a user "c" in a ralm "d", they may log in by
specifying "c" or "c@d", with equivalent results.
This ensures that user names can be specified either in the regular
short syntax or with a realm appended, and both are accepted. (The
latter of course only if the record actually defines a realm)
Uses the newly added policy-digest verb of systemd-measure, for the same
purpose: build a UKI and get digests for the .pcrsig section out, so
that they can be offline signed and reattached
When doing offline signing we need to know the exact payload
to sign, and the 'calculate' verb doesn't really show that, it
shows the PCR values. But what we sign is the hash of the policy.
So add a new verb that outputs the json payload that goes in the
.pcrsig section, without the .sig object, so that we can take them
and give the .pol object to an offline and asynchronous signing
service, such as SUSE's Open Build Service, and then add the .sig
object to the json and attach it to a UKI.
This doesn't make the RNG cryptographic strength, but if we have it
easily accessible, why not include the pidfd id. It is after all not
vulnerable to reuse.
Note that this drops a lot of "const" qualifiers on PidRef arguments.
That's because pidref_is_self() suddenly might end changing the PidRef
because it acquires the pidfd ID.
We had this previously already with pidfd_equal(), but this amplifies
the problem.
I guess we C's "const" doesn't really work for stuff that contains
caches, that is just conceptually constant, but not actually.
I just wanted to switch the machine id setup code to use chase() or its
changes, given it supports --root=/--image= operation. That turned out
to be a rabbit hole, and became much bigger...
This is shown every time nspawn is started, which is annoying
and there's nothing a user can do about it, since it depends on
an extremely new kernel. Downgrade to debug.
Follow-up for 611ae59888
Fixes a bug introduced by 2f0aa9a804.
In the offending commit, `sd_varlink_server_listen_auto()` is used. That
may add file descriptors of netlink socket for uevent and legacy control
socket varlink server. Then, udevd may fail to receive uevents.
let's move final processing of the filename out of the loop, and apply
it in all cases, uniformly, even if we are asked to only return the
final filename.
This also implies the new CHASE_MUST_BE_DIRECTORY flag in case the
specified path ends in a slash. This makes the rules stricter, it means
we'll be closer to how this is handled in kernel: if a path ends in a
slash it can never refer to a non-directory.
If we operate relative some explicit rootfs the reason for the sync()ing
is not really given, we are not really acting as a milestone at boot,
but "offline".
This allows using CHASE_MKDIR_0755 without CHASE_NONEXISTENT or
CHASE_PARENT, so that it will create the final component of the path
too should it be missing.
This is really useful as a mkdir_p() replacement that returns an fd to
the final component, and knows how to operate relative to a root fs.
Kinda reverts 4ea0bcb922 (which only
refused the flags combination which didn't work, instead of making it
work, which is what this commit does.)
This also corrects behaviour if CHASE_MKDIR_0755 is used in one more
way: we'll now always open the dir as O_PATH. This is generally the
better idea, but matters in particular once with allow using
CHASE_MKDIR_0755 to create the final component: we should uniformly
return an O_PATH dir that must be converted to a proper fd first before
using it.