Userns container in containers #351
Conversation
|
@avagin Thanks for looking at this. Spoke to @mrunalp and @LK4D4 about this, and I understand that it is possible to "fool" the container if you nest 2 levels in usernamespaces, and invalidate my check(map 1000 to 0 in level 1, and map 0 to 0 in level 2, so level 2 uid_map can portray itself as root on the host). An alternative is to indicate in runtime.json that the host has usernamespace limitations, meaning a non root user from the original parent host has been mapped to root user somewhere in the uid_map hierarchy. RunC will use this to behave the way it does when container is usernamespaced(don't mknod, don't write to devices.allow). |
Added a check on devices for hosts that are themselves usernamespaced containers. It is not possible for a non-root host process to set the devices.allow and devices.deny, and therefore this patch skips that for host processes which have a non-root uid_map. Signed-off-by: Abin Shahab <ashahab@altiscale.com>
ashahab-altiscale
force-pushed
the
350-container-in-userns-container
branch
from
34b9f16 to
7df8b4a
Compare
|
Are we okay closing this and using some other means? |
|
Yes I can close it. The use-case is still relevant. Containers should not make subprocesses inside aware of the fact that they are inside containers. |
Regenerate ffjson for Timeout field
Through 6734c7a (Merge pull request opencontainers#370 from vbatts/json_schema_and_examples, 2016-04-11). The only unlisted changes to master were a brief run with ffjson (opencontainers#343, opencontainers#351), but that was pulled out due to gccgo issues in opencontainers#363. Signed-off-by: W. Trevor King <wking@tremily.us>
3 participants
Added a check on devices for hosts that are themselves usernamespaced
containers. It is not possible for a non-root host process to set the
devices.allow and devices.deny, and therefore this patch skips that for
host processes which have a non-root uid_map.
Signed-off-by: Abin Shahab ashahab@altiscale.com