| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Whenever the host & embedded records are reconciled, the host & embedded
blob directories are now reconciled too in the same direction.
Reconciling the blob directories serves exactly the same purpose as
reconciling the user records, and thus should behave in the same way.
|
| |
|
|
|
| |
This function took an extra argument that it never used. This commit
cleans that up
|
| |
|
|
| |
No functional change intended.
|
| |
|
|
| |
Also make btrfs_subvol_make() an openat style function.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by home_update_quota_auto() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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.
|
| |
|
|
|
|
| |
RUN_WITH_UMASK was initially conceived for spawning externals progs with the
umask set. But nowadays we use it various syscalls and stuff that doesn't "run"
anything, so the "RUN_" prefix has outlived its usefulness.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we want to operate on an already activated home area we so far
tried to reapply the uidmapping logic. We shouldn't do that, it's
already applied after all.
We only want to apply this for newly activated home areas. Hence check
for the right HomeSetupFlags flag for it HOME_SETUP_ALREADY_ACTIVATED.
The patch is actually in theory a two-liner. Except that so far we don#t
pass the HomeSetupFlags flags down all necessary functions where the
uidmap stuff will eventually run. Hence this larger than intended
commit.
|
| |
|
|
|
| |
Some of our operations did it one way, most the other. Let's unify on
the order that is more popular.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/run/systemd/user-home-mount before moving them to /home
This does what we already do for the LUKS backend: instead of mounting
the source directory directly to the final home dir, we instead bind
mount it to /run/systemd/user-home-mount (where /run/ is unshared and
specific to our own mount namespace), then adjust its mount flags and
then bind mount it in a single atomic operation into the final
destination, fully set up.
This doesn't improve much on its own, but it makes things a tiny bit
more correct: this way MS_NODEV/MS_NOEXEC/MS_NOSUID will already be
applied when the bind mount appears in the host mount namespace, instead
of being adjusted after the fact.
Doing things this way also makes things work more like the LUKS backend,
reducing surprises. Most importantly it's preparation for doing
uidmapping for directory homes, added in a later commit.
|
| |
|
|
|
|
|
| |
For the other backends we synthesize a "binding" section in the json
record of the user that stores meta info how a user record is "bound" to
the local host. It declares storage info and such. Let's do the same for
the directory/subvolume backends.
|
| |
|
|
|
|
|
|
|
| |
Let's migrate home_create_directory_or_subvolume() to also use HomeSetup
for storing its runtime objects we'd like to destroy in case of failure.
In the beginning this is just the root_fd, but later on we can add more.
No change in behaviour, just shifting things around.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We should drop caches if we are configured to do so in all cases where
we are done with home dir operations: except if that operation is
activation, because in that case we are not destroying anything, but
leaving it on.
Hence, turn off the flag that reminds us that we should drop caches
before exiting, once activation completed fully,
Follow-up for 86019efa4416d7b548cab321c15bc22a65463786
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in most cases we'd allocate the HomeSetup context object
in generic code in homework.c. But for some cases we allocated them
instead inside the specific code in homework-{cifs,directory,luks}.c
Let's clean that up, and systematically allocate it in the outer
"entrypoint" calls in homework.c instead of the inner ones.
This doesn't change much in behaviour (i.e. it just means when something
fails we'll now clean it up one stack frame further up). But it will
allow is to more easily work with the context objects, since we'll have
them around in all stack frames.
|
| |
|
|
|
|
|
| |
This is mostly preparation for further defined flags to be added in
later PRs/commits.
No change in behaviour just the flagsification.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This function is a destructor, hence it should be named like one.
(We usually use xyz_free() for a destructor that frees the object passed
itself. xyz_unref() we typically use for destructors that are similar,
but ref counted. xyz_done() usually is used for destructors which free
the members of an object, but not the object itself – to allow stack
allocation of objects. We don't strictly follow this, but it's good to
stick to rules wherever we can.)
No actual code change, just renaming.
|
| |
|
|
|
|
|
|
|
| |
These set of functions are constructors for an object called HomeSetup,
which has a destructor home_setup_undo(), hence to be reasonably
symmetric, let's call it home_setup*() too, instead of using a new verb
"prepare" for its name.
No actual code changes, just some renaming.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We want user records to be extensible, hence we shouldn't complain about
fields we can't parse. In particular we want them to be extensible for
our own future extensions.
Some code already turned the permissive flag when parsing the JSON data,
but most did not. Fix that. A few select cases remain where the bit is
not set: where we just gnerated the JSON data ourselves, and thus can be
reasonably sure that if we can't parse it it's our immediate programming
error and not just us processing a user record from some other tool or a
newer version of ourselves.
|
| | |
|
| |
|
|
|
|
| |
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
|
