Rework LCOW username setup/exec behavior#1178
Merged
dcantah merged 2 commits intomicrosoft:masterfrom Sep 29, 2021
Merged
Conversation
anmaxvl
approved these changes
Sep 28, 2021
ambarve
reviewed
Sep 28, 2021
3d136c4 to
2c0cb35
Compare
dcantah
commented
Sep 29, 2021
This change swaps to checking the OCI specs username field instead of our custom annotation to match upstream. The real change is in how what user an exec runs as is handled. In most places in Containerd an execed process gets assigned the process spec of the container it’s getting launched in (so it will inherit anything set on the container spec), but due to the nature of LCOW there’s some OCI spec fields we set in the UVM instead as they’re not able to be handled on the host (in a clean manner at least). One of these is the user for the container. On a Linux host, Containerd will check if the user exists in the filesystem for the container before setting the user on the spec. On LCOW we just have vhd’s with the contents of the layers when making the spec which makes this a bit infeasible, so we defer that work until we’re in the guest and then edit the spec if the user exists. This has the outcome that the user is never set on the containers spec on the host for LCOW, but we do have the final amended spec in the UVM with whatever user was requested (or was set in the image via USER and so on). The way this is handled is by setting the Username field on the spec and then grabbing the uid:gid based on this string in the guest. The same is done for an exec. If a custom user is specified, try and find the uid:gid for the string provided. Otherwise, if Username is an empty string, just inherit whatever user the container spec contained. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
A previous change I'd made that was just for local testing changed the panic in our cri-containerd test suite to choose a set image. This simply reverts that. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
2c0cb35 to
b3b21da
Compare
anmaxvl
pushed a commit
to anmaxvl/hcsshim
that referenced
this pull request
Nov 17, 2021
Related work items: microsoft#1062, microsoft#1087, microsoft#1089, microsoft#1095, microsoft#1104, microsoft#1112, microsoft#1117, microsoft#1118, microsoft#1125, microsoft#1137, microsoft#1139, microsoft#1140, microsoft#1141, microsoft#1142, microsoft#1143, microsoft#1145, microsoft#1146, microsoft#1150, microsoft#1151, microsoft#1153, microsoft#1154, microsoft#1155, microsoft#1156, microsoft#1157, microsoft#1158, microsoft#1159, microsoft#1161, microsoft#1162, microsoft#1163, microsoft#1164, microsoft#1165, microsoft#1166, microsoft#1167, microsoft#1168, microsoft#1169, microsoft#1171, microsoft#1172, microsoft#1173, microsoft#1174, microsoft#1178
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change swaps to checking the OCI specs username field instead of
our custom annotation to match upstream. The real change is in how what
user an exec runs as is handled. In most places in Containerd an execed process
gets assigned the process spec of the container it’s getting launched in
(so it will inherit anything set on the container spec), but due to the nature
of LCOW there’s some OCI spec fields we set in the UVM instead as they’re not
able to be handled on the host (in a clean manner at least). One of these is
the user for the container.
On a Linux host, Containerd will check if the user exists in the filesystem for
the container before setting the user on the spec. On LCOW we just have vhd’s with
the contents of the layers when making the spec which makes this a bit infeasible, so
we defer that work until we’re in the guest and then edit the spec if the user exists.
This has the outcome that the user is never set on the containers spec on the host for
LCOW, but we do have the final amended spec in the UVM with whatever user was
requested (or was set in the image via USER and so on).
The way this is handled is by setting the Username field on the spec and then
grabbing the uid:gid based on this string in the guest. The same is done for
an exec. If a custom user is specified, try and find the uid:gid for the string
provided. Otherwise, if Username is an empty string, just inherit whatever user
the container spec contained.
Signed-off-by: Daniel Canter dcanter@microsoft.com