| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
In some places, "<n> bits" is used when more appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't really matter too much as both are static functions. But
it's confusing as hell both when debugging and reading code, given that
homed actually uses mount-util.c
Hence, let's just rename one of the two, to minimize confusion.
No actual change in behaviour.
(and sooner or later we might want to export mount-util.c's version of
the function, since it's generically useful)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
|
| |
|
|
| |
gcc will complain about all these with -Wformat-signedness.
|
| |
|
|
| |
Fixes #24117.
|
| | |
|
| |
|
|
|
|
| |
If people use nspawn in their $HOME we should allow this inodes owned by
this special UID to be created temporarily, so that UID mapped nspawn
containers just work.
|
| |
|
|
|
|
|
|
|
|
|
| |
for the container UID ranges
Apparently people really want to put high UIDs in their homedirs. Let's
add some minimal support for that.
Further discussion: https://github.com/systemd/systemd/pull/22239#issuecomment-1040421552
Inspired by, based on, and replacing #22239 by Christian Brauner.
|
| | |
|
| |\
| |
| | |
homed: allow per-user additional LUKS mount options
|
| | |
| |
| |
| |
| |
| | |
user record field
Fixes: #15120
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
See: #15120
|
| |/
|
|
|
|
|
|
| |
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.
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This teachs the LUKS backend UID mapping, similar to the existing
logic for the "directory", "subvolume" and "fscrypt" backends: the files
will be owned by "nobody" on the fs itself, but will be mapped to
logging in user via uidmapped mounts.
This way LUKS home dirs become truly portable: no local UID info will
leak onto the images anymore, and the need to recursively chown them on
activation goes away. This means activation is always as performant as
it should be.
|
| |
|
|
|
|
| |
No actual code change, let's just rename the first parameter, to make it
more generically useful in case the first argument is an arbitrary path,
not necessarily a username/realm.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new helper is not used yet, but it's useful for apply UID/GID
shifts so that the underlying home dir can use an arbitrary UID (for
example "nobody") and we'll still make it appear as owned by the target
UID.
This operates roughly like this:
1. The relevant underlying UID is mapped to the target UID
2. Everything in the homed UID range except for the target UID is left
unmapped (and thus will appear as "nobody")
3. Everything in the 16bit UID range outside of the homed UID
range/target UID/nobody user is mapped to itself
4. Everything else is left unmapped (in particular everything outside of
the 16 bit range).
Why do it like this?
The 2nd rule done to ensure that any files from homed's managed UID
range that do not match the user's own UID will be shown as "unmapped"
basically. Of course, IRL this should never happen, except if people
managed to manipulate the underlying fs directly.
The 3rd rule is to allow that if devs untar an OS image it more or
less just works as before: 16bit UIDs outside of the homed range will
be mapped onto themselves: you can untar things and tar it back up and
things will just work.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously the call did two things, and the second thing was optional
(depending on first arg being NULL). Let's simplify this and just make
it two distinct functions, where one calls the other.
This should make things a bit more readable, given that we called a
function called "…and_mount()" which didn't actually mount...
No actual code changes, just some refactoring.
|
| |
|
|
|
|
|
| |
We use this work dir a various places, and it's easy to mistype, hence
let the compiler detect this for us, and introduce a macro for it.
No code changes, just some search/replace.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Let's make umount_verbose() more like mount_verbose_xyz(), i.e. take log
level and flags param. In particular the latter matters, since we
typically don't actually want to follow symlinks when unmounting.
|
| | |
|
| | |
|
|
|
Fixes more or less: https://bugs.freedesktop.org/show_bug.cgi?id=67474
|
