IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 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.
This extends the close_all_fds() logic to overmount /proc with an empty
tmpfs, and/or to block close_range() via seccomp, so that we run the
test case for the function with the fallback paths.
This should make sure that we don't regress in limited environments or
older kernels.
Add special case optimization for a single exception fd. It's a
pretty common case in our codebase, and the optimization is simple
and means we don't need to copy/sort the exception array, so do it.
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.
