| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This function took an extra argument that it never used. This commit
cleans that up
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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.
|
|
|
|
| |
Fixes #24117.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
If we do automatic disk space rebalancing, we must be able to unlock the
encrypted volume for that in the background, thus we need to decryption
key around in userspace. Let's do this via the kernel keyring. This
allows us to do this in a relatively secure way, so that it sticks
around between homework invocations, but still is destroyed
automatically when homed goes down.
|
|
|
|
|
|
| |
This will be useful when we want to issue a resize operation right when
activating, where the HomeSetup object should be destroyed only after
both activation is done.
|
| |
|
|
|
|
| |
This is preparation for resizing automatically at login and logout.
|
|
|
|
|
| |
Let's make sure LUKS volumes are really definitely gone before we retun
in the deactivation logic.
|
|
|
|
| |
Preparation for extending it further down the line.
|
|
|
|
|
|
| |
Let's simplify things further a bit and move the destruction of the
temporary image file we operate on when creating a LUKS home into
HomeSetup, like all our other resources.
|
|
|
|
|
| |
Some of our operations did it one way, most the other. Let's unify on
the order that is more popular.
|
|
|
|
|
|
| |
We actually already detach/free the LUKS DM devices for most operations
via HomeSetup, let's move the creation logic to also do this, in order
to unify behaviour between operations.
|
|\
| |
| | |
homed: various cifs backend improvements
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allow specifying CIFS services in the format //host/service/subdir/… to
allow multiple homedirs on the same share, and not in the main dir of
the share.
All other backends allow placing the data store at arbitrary places,
let's allow this too for the CIFS backend. This is particularly useful
for testing.
|
|/ |
|
| |
|
|
|
|
| |
No actual code changes, just making a structure a bit shorter.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
It was supposed to be optional (i.e. there's a reason why we never
assert()ed on it), and in many codepaths it is, let's make sure it is
everywhere.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes: #20857
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's track the "dirty" state of a home directory backed by a LUKS
volume by setting a new xattr "home.home-dirty" on the backing file
whenever it is in use.
This allows us to later user this information to show a home directory
as "dirty". This is useful because we trim/allocate on log-out, and
if we don't do that a home directory will be larger than necessary. This
fact is something we should communicate to the admin.
The idea is that when an admin sees a user with a "dirty" home directory
they can ask them to log in, to clean up the dirty state, and thus trim
everything again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
homed maintains two or three copies of the user's identity record per
home directory: one on the host, one inside the LUKS header, and one
embedded in the home directory.
Previously we'd insist that if a user logs in they have to authenticate
against all three, as a safety feature. This broke logging into
unfixated records however, since in that case the host version is
synthetic and thus does not carry any authentication data.
Let's hence losen the strictness here: accept authentication against
host records that carry no auth data. This should be safe as we know
after all that the second/third record will catch invalid accesses.
Fixes: #15178
|
|
|
|
| |
property
|
|
Fixes more or less: https://bugs.freedesktop.org/show_bug.cgi?id=67474
|