The utility function parse_integrity_options is used to both validate
integritytab options or validate and return values. In the case where
we are validating only and we have specific value options we will
assert.
Those devices show up as /sys/devices/vif-N, let's use that number
to name them enXN.
Without this, all schemes fail and they keep the kernel names, which can
be racy.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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.
Now that all objects we need to destroy are managed by the HomeSetup
object we can drop our manual destruction path and just use the normal
clean-up logic implemented for HomeSetup anyway. More unification, yay!
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.
Now that we stored all our different objects inside the HomeSetup
structure, we can get rid of our manual clean-up path, since
home_setup_done() will clean up everything stored therein anyway, in the
right order.
This is the main reason we moved everything into HomeSetup in the
previous commits: so that we can share clean-up paths for these objects
with everything else.
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.
This is just some minor refactoring, to make these two operations work
like the rest.
home_lock_luks() will now use the root_fd field of HomeSetup already,
but for home_unlock_luks() + home_deactivate() this change has no effect for now. (But a
later commit will change this.)
This is useful since certain shares can only be mounted with additional
mount flags. For example the SMB share in modern AVM Fritz!Boxes
requires "noserverino" to be set to work from Linux.
Unfortunately mount.cifs doesn't really let us know much about the
reason for the failure. Hence, assume it's caused by a bad password, and
retry on any failure with additional passwords that we might have.
A loop to do this was always in place, but none of the possible
codepaths actually allowed to iterate more than once. Fix that.
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 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.
Of course unlike in the LUKS case there's not actually any user record
stored in the LUKS header, so what we pass here will always be NULL.
The reason why I am changing is to make this more alike the other
home_activate_xyz() calls, and passing this around doesn't hurt.
(A later commit will replace all backend-specific home_activate_xyz()
calls by a single one)
Similar to the same chage we did for the directory backend. Let's always
path the setup context object, i.e. HomeSetup, and store whatever we set
up in there.
No actual change in behaviour.
