This is useful when we start to call mountfsd from root, for example
from the tests where we just use a simple squashfs/erofs.
Note that this requires the caller to be root, and it will be rejected
otherwise, as such images are classified as 'unprotected' and the
enforced policy does not accept them for unprivileged users.
See the second commit for details.
I think we might want to apply the same treatment to nss and pam
modules. Asserting in such "plugin code" seems iffy. But this PR doesn't
change those in any way.
As discussed in this thread:
https://github.com/redhat-performance/tuned/issues/798#issuecomment-3197697654
/usr/share/factory/ is not intended to be read from by programs,
but the wording in the FHS can be misread to think that programs
should be using /usr/share/factory/ as the vendor supplied configuration
directory rather than something like /usr/lib/foo/ or /usr/share/foo/.
This commit points developers to the UAPI configuration spec for how to
make their programs hermetic /usr/ compatible.
Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>
Previously, when compiled in developer mode, a call into libsystemd with
invalid parameters would result in an abort. This means that it's effectively
impossible to install such libsystemd in a normal system, since various
third-party programs may now abort. A shared library should generally never
abort or exit the calling program.
In python-systemd, the test suite calls into libsystemd, to check if the proper
return values are received and propagated through the Python wrappers.
Obviously with libsystemd compiled from git, the test suite now fails
in a nasty way.
So rework the code to set assert_return_is_critical similarly to how we handle
mempool enablement: the function that returns true is declared as a week
symbol, and we "opt in" by linking a file that provides the function in
libsystemd-shared. Effectively, libsystemd and libudev always have
assert_return_is_critical==false, and our binaries and modules enable it
conditionally.
The function internally does caching which means that the result must
always be the same, the definition of a pure function. The compiler might
be able to optimize some repeated calls to the function.
Although extremely unlikely, there is a race present in solely checking the
$LISTEN_PID environment variable, due to PID recycling. Fix that by introducing
$LISTEN_PIDFDID, which contains the 64-bit ID of a pidfd for the child process
that is not subject to recycling.
An unprivileged process cannot reduce its own capability bounding set,
hence, while it is nice to reduce the set, let's not log about it
loudly, in case we are invoked unpriv (which we explicity support these
days after all).
An unpriv process also cannot detach from its netns, hence also
downgrade the warning to a debug message.
When invoked unprivileged, let's use a transiently allocated userns, so
that we can properly untar UIDs/GIDs so that the trees appear owned by
the foreign UID/GID range.
Let's introduce a single helper that determines where to download images
to, taking all three primary parameters into account: the image class,
the runtime scope and whether to do runtime or persistency.
Then port everything over to this.
This not only cleans things up, but makes sure the importd backends
actually properly can deal with per-user downloads, as before we never
took the runtime scope into account for determining download location.
The runtime scope logic is internally already in place, let's expose
this via getopt() command line too. This way importd later can propagate
the invocation scope down to the backends.
When operating in unprivileged mode we might not be able to execute the
necessary operations to make a disk image read-only (because
FS_IMMUTABEL_FL needs privs for example), and syncing (because for that
we might need to open the root inode, but that might not be possible
from the outside).
Let's deal with that by making these operation optional: if they work
great, if not they don't.
Sometimes it's quite useful to pin a source dir via an fd, as well as a
target dir the same way, and then ask copy_tree_at_full() to copy the
contents from one to the other. Make this possible, by allowing 'to' be
NULL. (Previously, it had to be non-NULL, i.e. the function would always
create a new dir, no matter what.)
Note that we only support that for dir inodes.
Fixes the following warning:
TEST-75-RESOLVED.sh[2251]: ++ restart_resolved
TEST-75-RESOLVED.sh[2251]: ++ systemctl stop systemd-resolved.service
TEST-75-RESOLVED.sh[2271]: Stopping 'systemd-resolved.service', but its triggering units are still active:
TEST-75-RESOLVED.sh[2271]: systemd-resolved-monitor.socket, systemd-resolved-varlink.socket
Fn + F1 which is the shortcut for toggling the touchpad on/off sends
atkbd scancodes f7 (first press) + f8 (second press) just like on various
other Clevo models. Add the V64x_V65xAU model to the list of models where
these scancodes are mapped to touchpad-toggle.
This has irked me for a while. For me network configuration is the stuff
we store on disk in configuration file. And networkd then *applies* the
configuration. But the units so far claimed that networkd was the
"configuration" itself. Which I guess might make sense to some, but to
me sounds a bit unprecise. Let's clean this up, and call what networkd
is doing "Network Management".
If one of PID, UID, GID, or SIGNAL is missing, then parse_uid() and
friends in the below will trigger assertion. This fixes that.
Also, only PID, UID, GID, SIGNAL, and COMM are mandatory fields, but
others are not, hence this drops others from the condition.
Moreover, this mekes 'coredumpctl --list' not fail even if there exists a
broken coredump entry in journal.
Aider is an open-source AI coding assistant. When used, it generates history,
cache, and other files in the project. To prevent these files from being committed, you need to add .aider* to your .gitignore file
By giving priority to --background= we prevent users from opting
out of coloring if an explicit color is chosen by a tool wrapping
one of our own tools. Instead, let's give priority to the environment
variable, so that even if our tools are wrapped by another tool with
a different background, users can still opt out of coloring just by
setting the environment variable, which has a high chance of being
forwarded to the invocation of our own tools which makes it easy to
use to disable color tinting globally if requested by the user.
The DNS RR class is a weird thing, and IRL always set to IN (i.e. 0x1).
Let's hence make it something that can be specified optionally, and
imply IN if not specified.
This makes it a bit nicer to put together suitable json resource record
keys from the command line.
We want to reuse these generic DNS concepts in resolved hook
implementations, hence move them to shared code.
(This also enables us to immediately remove som SVCB record handling
duplicate definitions.)
No real code changes, just some moving around of things.
This can lead to booting with a completely garbled command line with characters
being interpreted as miscellaneous CJK or symbols.
According to the UEFI spec, the optional data of the load option is just a
binary data buffer.
Luca Boccassi
theSillywhat
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Daan De Meyer
Ryan Brue
Daniel Foster
Septatrix
Yu Watanabe
Hans de Goede
Ivan Kruglov
nkraetzschmar
jouyouyun
Thomas Mühlbacher
Nick Labich