So far, if some component mounts a DDI in some local mount namespace we
created a temporary mountpoint in /tmp/ for that. Let's instead use the
same directory inode in /run/ instead. This is safe, since if everything
runs in a local mount namespace (with propagation on /run/ off) then
they shouldn't fight for the inode. And it relieves us from having to
clean up the directory after use. Morever, it allows us to run without
/tmp/ mounted.
This only moves dissect-image.c and the dissec tool over. More stuff is
moved over later.
/sys/power/resume is always populated by the initrd, while
/sys/power/resume_offset might have been populated by
the kernel itself. Therefore, if the user is using an initrd
that doesn't include resume hook, the hibernation would fail,
which is expected. However, it was hard to track down the real
problem, since the previous log message suggested that resume=
is not set through kernel cmdline.
As it turns out we do this in a similar way at various times (and
sometimes incorrectly), hence add a common implementation to share the
code and fix the incorrect behaviour.
The parameter returns the flags field of the reply message. This is only
relevant in very few cases, hence drop it from the call, but keep it in
a more generic varlink_call_full() call for those who need it.
Do something similar for varlink_callb().
It's OK if callers don't want to know the varlink error string. But in
that case return the fact the call failed via the return value, as a
negative errno as usual, to make sure it's not accidentally ignored.
Similar for varlink_observe()
In varlink errors can have parameters (and they regularly do, for
example the io.systemd.System error we generate carries the errno in its
parameter), hence it's essential that varlink_oberserve collects that
properly and returns it too.
The commit e3acb4d24c changed how we format a
TPM2B_PUBLIC object from an openssl PEM RSA key if it used the TPM-defined
"default" RSA exponent, to instead set the TPM2B_PUBLIC RSA exponent to the
special-case value of 0. This broke backwards compatibility with
previously-sealed data. The previous commit fixed our code to no longer use the
"special case" exponent value of 0, while this commit adds a fallback check for
any sealed data that used the exponent value of 0. Now unsealing should work
for sealed data that used either method (either 0 or the actual value).
The openssl default value for an RSA key exponent value is 0x10001, and the TPM
specification defines a exponent value of 0 as representing this value. The
systemd code that converted an RSA PEM public key to a TPM2B_PUBLIC object
previously used the exponent value directly, but commit
e3acb4d24c changed the conversion to use the
special case exponent value of 0 for any RSA key with an exponent value of
0x10001.
Because the entire TPM2B_PUBLIC object is used to calculate its "name", this
difference in exponent value (0x10001 vs 0) introduced a change in the key
"name". Since the Authorize policy uses the key "name" directly in its policy
session hash value, this change resulted in new systemd code being unable to
properly unseal any data (e.g. a LUKS volume) that was previously sealed.
This reverts the code to no longer override an RSA exponent value of 0x10001
with the special case value of 0.
Fixes a bug introduced by commit e3acb4d24c.
Fixes: #30546
Now that we can selectively suppress only sensitive fields in JSON
objects we can reenable debug logging for incoming messages, which was
removed in 2e3414660c.
This makes Varlink fully debuggable again: we'll see both incoming and
outgoing messages, only the sensitive fields are suppressed.
See: #30578
Previously, the flag would completely refuse formatting a JSON object if
any field of it was marked sensitive. With this change we'll simply
replace the subobject with the string "<sensitive data>", and show
everything else.
This is tremendously useful when debugging, since it means that we can
again trace varlink calls through the stack: we can show all the message
metadata and just suppress the actually sensitive parameters.
The ability to debug this matters, and we should not hide more
information that we can get away with, to keep things debuggable and
maintainable.
Let's export this function, so that we can use it elsewhere. Also, while
at it, let's cache the result in a flag. This is only safe if the result
is positive, since we allow the flag to be enabled at any time down thre
tree somewhere, which we need to look at. (We never allow it to be
turned off however)
So far the varlink logic honoured the "sensitive" flag of output
messages. Let's add something similar for input messages. Since we don't
really know incoming messages, the flag simply controls whether the
"parmaeters" field of all incoming messages should be marked as
sensitive.
Then, turn this on in the credentials logic and in homed, since both
deal with credentials.
Don't recalculate the overall offset entirely each time we process
another header. Instead, if we already validated an earlier offset, just
reuse the result, it's readily available in 'p'.
No change in behaviour, just a bit of code simplification.
A positive return value means "access granted", hence if we already
reply to the method call don't accidentally return positive.
Follow-up for: d04c1a1c8e
varlink_server_listen_auto() is supposed to be the one-stop solution for
turning simple command line tools into IPC services. They aren't easy to
test/debug however, since you have to invoke them through a service
manager.
Let's make this easier: if the SYSTEMD_VARLINK_LISTEN env var is set,
let's listen on the socket specified therein. This makes things easier
to gdb: just run the service from the cmdline.
Let's improve debuggability of varlink IPC transactions, and separate
out log messages triggered by the IPC info from others, by prefixing
them with a specific prefix.
Adrian Vovk
Lennart Poettering
Luca Boccassi
Mike Yuan
Dan Streetman
Ronan Pigott
Daan De Meyer
Yu Watanabe
David Tardon