New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
homed uidmapping (just for the directory backend) #21136
Conversation
|
0632b45
to
d6db75d
Compare
force pushed a new version, with the CI issue hopefully fixed |
test-process-util in CentOS is failing, but doesn't seem related as the changes are contained in src/home - @mrc0mmand seen this before?
|
Yep, I've seen the a couple of times and it's definitely unrelated. |
d6db75d
to
8029f0f
Compare
return TAKE_FD(userns_fd); | ||
} | ||
|
||
int home_shift_uid(int dir_fd, const char *target, uid_t stored_uid, uid_t exposed_uid, int *ret_mount_fd) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be useful in the near future for other components, maybe add it directly to the library (eg, basic/namespace-util.c or similar)? The only homed-specific part as far as I can see are HOME_UID_MIN and HOME_UID_MAX, which could simply be taken as parameters.
Then there could even be a unit test added, which would be quite useful to ensure the fallback/detection works nicely everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i am always concerned about putting stuff in src/basic/ + src/shared/ if it doesn't have at least two users — unless it's a totally obvious case.
I am not sure about this one. Yes, this might be something we can reuse later, but I am pretty sure it's something that will require further modifications. But if that's the case we might as well move it into generic code later on. Unless the needed semantics of the other stuff are really clear and obvious I doubt we can generalize this properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, makes sense
8029f0f
to
5edd7ea
Compare
added the assert. (actually a few others too) ptal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question, and one minor suggestion.
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.
…ting record 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.
…ser-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.
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.
5edd7ea
to
cf5115f
Compare
made the two indicated changes. since so minor upgrading green label again |
This is the first part of #21135, to make things easier to digest for reviewers.
This contains uidmapping for the directory backend only. the fscrypt + luks + cifs changes are left out and will be submitted in a separate PR later on.