homed: reset HomeSetup.undo_dm field when deactivating home dir the official way
There are two ways to deactivate a home dir: the official way if someone
calls "homectl deactivate" or something similar. Or the
error-case/side-effect code path, where we unwind exactly what we
already set up.
The .undo_dm field is supposed to tell us whether we shall still detach
the DM device. We forgot to update it in the official code path. Add
that. (We did it correctly in the error case codepath already).
(The issue is minor: if we forget to reset it in the clean code path,
then we'll try to unmount again what is already unmounted in the error
code paths, but since we ignore errors there — to not "stack" errors –
we never noticed and there's no bad effect of it)
After reading https://simonbyrne.github.io/notes/fastmath/ I think we
should drop -ffast-math. The JSON code actually looks for NaN, so the
fact it becomes unreliable kinda sucks.
Moreover, we don't do any number crunching. We use floating point fields
only sporadical for trivial math. Hence the optimization is entirely
unnecessary.
homework: rework how we disassemble a home dir in home_deactivate()
Let's first move the home dir to a new mount point that is only visible
in our own private namespace. Then, do FITRIM and stuff there, so that
we know the regular userspace can't interfere with that, and we know
that the home fs is not used anymore.
(This will become even more important once we add auto-grow/auto-shrink
for home dirs)
Slava Bacherikov [Sat, 13 Nov 2021 12:43:04 +0000 (14:43 +0200)]
network: change link group type to int32
Both linux kernel kernel and iproute2 uses int32 type for a link group
attribute and -1 has a special meaning, so setting it to 4294967295
would make it -1 in the linux kernel (and ip link cmd).
by moving the read permissions to the top level and
granting additional permissions to the specific jobs.
It should help to prevent new jobs that could be added
there eventually from having write access to resources they
most likely would never need.
Judging by https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
it should be enough to grant the "read contents" permission to
most of our actions. The "read metadata" permission is set impliciclty
somewhere and can't be set via the "permissions" setting:
```
The workflow is not valid. .github/workflows/linter.yml (Line: 14, Col: 3): Unexpected value 'metadata'
```
With glibc-2.34.9000-17.fc36.x86_64, dynamically programs newly fail in early
init with a restrictive syscall filter that does not include @system-service.
I think this is caused by 2dd87703d4386f2776c5b5f375a494c91d7f9fe4:
nptl: Move changing of stack permissions into ld.so
All the stack lists are now in _rtld_global, so it is possible
to change stack permissions directly from there, instead of
calling into libpthread to do the change.
It seems that this call will now be very widely used, so let's just move it to
default to avoid too many failures.
shared: split out UID allocation range stuff from user-record.h
user-record.[ch] are about the UserRecord JSON stuff, and the UID
allocation range stuff (i.e. login.defs handling) is a very different
thing, and complex enough on its own, let's give it its own c/h files.
homed: include actual fs type + access mode as part of "status" section of user record
So far we have two properties for the intended fstype + access mode of
home dirs, but they might differ from what is actually used (because the
user record changed from the home dir, after it was created, or vice
versa). Let's hence add these props also to the "status" section of user
record, which report the status quo. That way we can always show the
correct, current settings.
homed: allow querying disk free status separetely from generating JSON from it
We later want to query per-home free status for implementing automatic
grow/shrink of home directories, hence let's separate the JSON
generation from the disk free status determination.
This adds to new helpers: keyring_read() for reading a key data from a
keyring entry, and TAKE_KEY_SERIAL which is what TAKE_FD is for fds, but
for key_serial_t.
The former is immediately used by ask-password-api.c
homed: add env var for overriding default mount options
This adds an esay way to override the default mount options to use for
LUKS home dirs via the env vars SYSTEMD_HOME_MOUNT_OPTIONS_EXT4,
SYSTEMD_HOME_MOUNT_OPTIONS_BTRFS, SYSTEMD_HOME_MOUNT_OPTIONS_XFS.
This follows what Fedora did with 34: enables compression by default,
lowering IO bandwidth and reducing disk space use, at the price of
slightly higher CPU use.
In delete_rule(), we already checked that the rule name is a valid file name
(i.e. no slashes), so we can just trivially append.
Also, let's always reject rules that we would later fail to delete. It's
probably better to avoid such confusion.
And print the operations we do with file name and line number. I hope this
helps with cases like https://github.com/systemd/systemd/pull/21178. At least
we'll know what rule failed.
$ sudo SYSTEMD_LOG_LEVEL=debug build/systemd-binfmt
Flushed all binfmt_misc rules.
Applying /etc/binfmt.d/kshcomp.conf…
/etc/binfmt.d/kshcomp.conf:1: binary format 'kshcomp' registered.
namespace: make tmp dir handling code independent of umask too
Let's make all code in namespace.c robust towards weird umask. This
doesn't matter too much given that the parent dirs we deal here almost
certainly exist anyway, but let's clean this up anyway and make it fully
clean.
namespace: make whole namespace_setup() work regardless of configured umask
Let's reset the umask during the whole namespace_setup() logic, so that
all our mkdir() + mknod() are not subjected to whatever umask might
currently be set.
This mostly moves the umask save/restore logic out of
mount_private_dev() and into the stack frame of namespace_setup() that
is further out.
Jonas Witschel [Thu, 11 Nov 2021 21:25:40 +0000 (22:25 +0100)]
test: add regression test for systemd-run --scope [--user]
systemd-run --scope --user failed to run in system 249.6, cf. #21297. Add tests
for systemd-run --scope and systemd-run --scope --user to make sure this does
not regress again.
projects / thirdparty / systemd.git / log
