varlink: make 'userdata' pointer inheritance from varlink server to connection optional
@keszybz's right on
https://github.com/systemd/systemd/pull/18248#issuecomment-760798473:
swapping out the userdata pointer of a live varlink connection is iffy.
Let's fix this by making the userdata inheritance from VarlinkServer
object to the Varlink connection object optional: we want it for most
cases, but not all, i.e. all those cases where the calls implemented as
varlink methods are stateless and can be answered synchronously. For the
other cases (i.e. where we want per-connection objects that wrap the
asynchronous operation as it goes on) let's not do such inheritance but
initialize the userdata pointer only once we have it. THis means the
original manager object must be manually retrieved from the
VarlinkServer object, which in turn needs to be requested from the
Varlink connection object.
The userdata inheritance is now controlled by the
VARLINK_INHERIT_USERDATA flag passed at VarlinkServer construction.
core: make NotifyAccess= in combination with RootDirectory=/RootImage= work
Previously if people enabled RootDirectory=/RootImage= and NotifyAccess=
together, things wouldn't work, they'd have to explicitly add
BindReadOnlyPaths=/run/systemd/notify too.
Let's make this implicit. Since both options are opt-in, if people use
them together it would be pointless not also defining the
BindReadOnlyPaths= entry, in which case we can just do it automatically.
Benjamin Berg [Tue, 19 Jan 2021 13:59:42 +0000 (14:59 +0100)]
hwdb: Pull autosuspend rules from upstream libfprint
libfprint includes a list of known fingerprint readers that can be
autosuspended. Upstream libfprint generates this file from the USB IDs
registered to drivers and a list of well-known readers that are
currently unsupported.
This addresses the following comments by the Lennart:
---
hmm, so this now does two access() calls for the case where the fd is
not requested, and opens things up for races (theoretically, …). now,
the access() code path was in place for optimization, but if an optimization
is less sexy than the original (and i think it is less sexy, since more
than one syscall, and non-atomic), i think we shouldn't do the optimization.
maybe we should just always use open(O_PATH) now, and then fstat() it to
check if regular file, and then access_fd() it for checking if its executable.
Dan Streetman [Sun, 17 Jan 2021 22:46:12 +0000 (17:46 -0500)]
udev: use DEFINE_MAIN_FUNCTION in cdrom_id
This was failing s390x ubuntu ci due to an old version of binutils;
the binutils package in use for ubuntu ci tests has been updated and
the build no longer fails, so this can use the macro again.
tree-wide: ignore messages with too long control data
Apparently SELinux inserts control data into AF_UNIX datagrams where we
don't expect it, thus miscalculating the control data. This looks like
something to fix in SELinux, but we still should handle this gracefully
and just drop the offending datagram and continue.
recvmsg_safe() actually already drops the datagram, it's just a matter
of actually ignoring EXFULL (which it generates if control data is too
large) in the right places.
This does this wherever an AF_UNIX/SOCK_DGRAM socket is used with
recvmsg_safe() that is not just internal communication.
EFI stubs don't matter, and libsystemd-shared-nnn.so is loaded through rpath,
and is doesn't need to and shouldn't be in $LD_LIBRARY_PATH. In effect, we only
ever need to add the main build directory to the search path.
import: optionally pull .verity + .roothash.p7s data when downloading
We already had support for downlading a .nspawn and a .roothash file,
let's make the set complete, and also download .verity + roothash.p7s if
it exists, as nspawn consumes that.
Since there are now four kinds of additional resources to acquire, let's
introduce a PullFlags flags value for this instead of separate 'bool'
variables, it's just too many to always pass those around on the
function parameter list.
import: ignore non-successful HTTP codes for collecing image metadata
Previously we'd collect the data from redirects too, which wasn't
particularly terrible, since these typically don't carry the data we
were interested in, but it's still incorrect to do so.
Properly reset all fields that have to do with the current GET job when
we restart things. Previously we freed/reset only some stuff, leaking
some memory even.
Previously the PullJob object took internal care of rerequested the
SHA256SUMS file, if requesting <image>.sha256 didn't work. This was a
weird a non-abstraction only used when actually getting the checksum
files.
Let's move this out of the PullJob, so that it is generic again, and
does roughly the same stuff for all resources it is used for: let's
define a generic .on_not_found() handler that can be set on a PullJob
object, and is called whenever with see HTTP 404, and may be used to
provide a new URL to try if the first didn't work.
This is also preparation for later work to support PKCS#7 signatures
instead of gpg signatures, where a similar logic is needed, and we thus
should have a generic infrastructure place.
This gets rid of the VerificationStyle field in the PullJob object:
instead of storing this non-generic field we just derive the same
information from the URL itself, which is safe, since we generated it
ourselves earlier.
fs-util/rm-rf: improve remove+free destructors to take and return NULL
Let#s make these helpers useful even without _cleanup_ logic, to destory
arbitary fields: make them OK wiht a NULL pointer as input, and always
return one as output.
Florian Westphal [Tue, 19 Jan 2021 08:25:15 +0000 (09:25 +0100)]
homed: fix build without p11kit
homectl-pkcs11.c: In function 'identity_add_pkcs11_key_data':
homectl-pkcs11.c:155:13: error: implicit declaration of function 'pkcs11_acquire_certificate' [-Werror=implicit-function-declaration]
systemctl: warn when importing environment variables with control characters
I don't think it is useful to warn about about environemnt variables where the user
explicitly configured some value. If they went through the effort of escaping the cc
to include it in the setting (e.g. Environment="VAR=\efoo"), and we pass this through,
there isn't anything to warn about. This also applies to 'systemctl set-environment',
where the variable name and value are passed as arguments.
The only case where the warning *might* be useful is where the user might be
surprised by the value. This occurs when importing variables from the inherited
environment, i.e. in 'systemctl import-environment'. In not convinced that this is
useful, since the user better control their shell environment anyway.
$ systemctl import-environment
Calling import-environment without a list of variable names is deprecated.
Environment variable $LESS_TERMCAP_mb contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_md contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_me contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_se contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_so contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_ue contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_us contains control characters, importing anyway.
Environment variable $ZZZ contains control characters, importing anyway.
Allow control characters in environment variable values
So far, we would allow certain control characters (NL since b4346b9a77bc6129dd3e, TAB since 6294aa76d818e831de45), but not others. Having
other control characters in environment variable *value* is expected and widely
used, for various prompts like $LESS, $LESS_TERMCAP_*, and other similar
variables. The typical environment exported by bash already contains a dozen or
so such variables, so programs need to handle them.
We handle then correctly too, for example in 'systemctl show-environment',
since 804ee07c1370d49aa9a. But we would still disallow setting such variables
by the user, in unit file Environment= and in set-environment/import-environment
operations. This is unexpected and confusing and doesn't help with anything
because such variables are present in the environment through other means.
When printing such variables, 'show-environment' escapes all special
characters, so variables with control characters are plainly visible.
In other uses, e.g. 'cat -v' can be used in similar fashion. This would already
need to be done to suppress color codes starting with \[.
Note that we still forbid invalid utf-8 with this patch. (Control characters
are valid, since they are valid 7-bit ascii.) I'm not sure if we should do
that, but since people haven't been actually asking for invalid utf-8, and only
for control characters, and invalid utf-8 causes other issues, I think it's OK
to leave this unchanged.
systemctl: print a warning when trying to import a nonexistent variable
I was quite confused what is happening:
$ XXX=xxx
$ systemctl --user import-environment XXX
$ systemctl --user show-environment | grep XXX
(nothing)
Obviously, 'export XXX' was missing. Without any indication why the
export is not happening, this can be hard to figure out.
Another option would be to error out. But so far we didn't, and doing
that could break some script which optimistically tries to export some
variables, if present.
units: add systemd-sysext.service unit for auto-activating extensions at boot
We'll leave this as opt-in (i.e. a unit that must be enabled
explicitly), since this is supposed to be a debug/developer feature
primarily, and thus no be around in regular production systems.
projects / thirdparty / systemd.git / log
