This new setting can be used to specify mount options that shall only be
added to the mount option string if the kernel supports them.
This shall be used for adding "usrquota" to tmp.mount without breaking compat,
but is generally be useful.
This adds a new --lightweight=yes/no switch which allows controlling
whether the invoked service will have the service manager around or not.
Moreover, this changes that if the target user is root it will now
support to the lightweight mode, i.e. run0 towards root will no longer
pull in the service manager (a real tty login via getty still will
though!).
My thinking here is that quickly raising privileges via run0 probably
shouldn't be considered a proper login but just something short lived,
temporary for a single command or similar.
This new session class is to "user" what "background" is to
"background-light": it doesn't cause the per-user service manager to
start.
This new session class is now the default if no session class was
provided at session registration time and the following conditions hold:
1. The session is not graphical
2. The user is not a regular user (but not root)
Or in other words root and system users won't get a service manager
started automatically if they go through a PAM session as part of things
like cron or ftp. They will however still get one if they log in
graphically.
This changes behaviour a bit, but hopefully in OK was.
This also makes "background-light" for system users incl. root.
This addresses one of the ideas discussed in #34988.
This makes things a bit faster (because it cuts down a bit on
roundtrips) and prepares ground so that one day we can let logind run in
earlier boot already, making it a bit less special.
communication between logind and pid1 is still dbus only, hence there's
a lot of room for further improvement I guess.
This PR introduces io.systemd.MachineImage.SetPoolLimit method which is
alternative to DBus's SetPoolLimit.
This is last function for org.freedesktop.machine1 Dbus interface
With the latest changes, this is not required anymore as mkosi sandbox
will set up the proper $PATH to make sure the executables from the build
directory are used.
If we save journals in /tmp, we can run a larger number of tests in
parallel so let's make use of the larger number of CPUs if the tests
run on a beefy machine.
The integration-test-setup calls require StateDirectory= but some
tests override the test unit used which then won't have StateDirectory=
so let's move StateDirectory= into the dropin as well to avoid this
issue.
The journal isn't the best at being fast, especially when writing
to disk and not to memory, which can cause integration tests to
grind to a halt on beefy systems due to all the systemd-journal-remote
instances not being able to write journal entries to disk fast enough.
Let's introduce an option to allow writing in progress test journals
to use /tmp which can be used on beefy systems with lots of memory to
speed things up.
This effectively reverts b8582198ca
as I can not get the testing farm bare metal machines working
downstream and even if I managed to, without also using the testing
farm bare metal machines upstream (for which there is no capacity),
the setup would very quickly bitrot anyway so we'll just run the
container based tests for now.
pam_systemd is used to create logind sessions and to apply extended
attributes from json user records. Not every application that creates a
pam session expects a login scope, but may be interested in the extended
attributes of json user records. Session class "none" implements this
service by disabling logind for this session altogether.
---
Closes: #34988
When running the integration tests downstream, it's useful to be
able to test that a new systemd version doesn't introduce any AVC
denials, so let's add a knob to make that possible.
If we're not running interactively, there's no point in the features
from integration-test-setup.sh which are intended for interactive
development and debugging so lets skip adding it in that case.
Even though udevadm accepts relative syspath, previously, udevadm
could not use relative path to device node:
===
$ cd /dev
$ udevadm info sda
Bad argument "sda", expected an absolute path in /dev/ or /sys/ or a unit name: Invalid argument
$ udevadm info /usr/../dev/sda
Unknown device "/usr/../dev/sda": No such device
===
With this change, both the above cases work fine.
Note, still sd_device_new_from_devname() requires absolute path starts
with /dev/, for safety.
Downstream we sometimes end up with machines with lots of CPUs which
leads to running out of memory when trying to run the tests in VMs.
So let's switch to a different heuristic when we have lots of CPUs to
avoid running out of memory.
We enforce quite strict rules on naming userns we assign uid ranges to
for users. So strict that they are hard to get right for clients. hence,
let's optionally mangle provided strings so that they work for us.
This should make it much easier to work with the API, as something
reasonable happens regarldess what kind of garbage a client sets as
name.
mangling the name is opt-in for clients, so that there's tight control
for the client on the name, but also "fire and forget".
This improves operation in unprivileged userns environments, where
unpriv user code might invoke a container with a delegated userns UID
range, and thus ends up with a subcgroup owned by another UID. With this
patch any user is always allowed to remove their own cgroups even if it
has subcgroups owned by other users.
This removes a DoS of sorts, and enforces the rule that users strictly
own everything below cgroups they own.
This is a test for the previous commits: we create an unpriv, delegated cgroup in
--user mode, then create a subcgroup that is owned by some other user
(to mimic the case where an unpriv user got a userns with delegated UIDs
assigned), and then try to stop the unit. traditionally this would fail,
because our unpriv systemd --user instance can't remove the subcrroup
owned by someone else. With the earlier patches this is addressed.
This PR introduces io.systemd.Machine.CopyFrom and CopyTo method which
are DBus alternatives of:
- CopyFromMachine
- CopyToMachine
- CopyFromMachineWithFlags
- CopyToMachineWithFlags
The PR also contain tests
