You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When images are built by a deamon running with user namespaces, extended attribute capabilities are saved in v3 format, thereby including the UID of the root user of the user namespace.
Running such images inside another runtime, either with no user-namespacing, or with a different user-namespace setup for the UID of the root user, the effective bit is ignored by execve(2) as the UID does not match.
For images built with the userns feature to be portable across runtimes, we need capabilities to be saved in v2 format in the image layer archives.
In the output above, the 2nd set of Cap* should match the first set. execve(2) has ignored the effective bit on sleep-test in the 2nd case because the root UID stored in the extended attribute does not match the runtime.
Describe the results you expected:
Expect to be able to run images built on user-namespaced environments in non-user-namespaced environments (or with a different user-namespace owner UID) and have the effective bit for capabilities honoured by execve(2).
Additional information you deem important (e.g. issue happens only occasionally):
This is for the non-user-namespaced configuration, however the user-namespaced configuration is identical, with userns added to the Security Options section:
Capabilities are serialised in VFS_CAP_REVISION_3 when an image is
built in a user-namespaced daemon, instead of VFS_CAP_REVISION_2.
This adds a test for this, though it's currently wired to fail if
the capabilities are serialised in VFS_CAP_REVISION_2 instead in this
situation, since this is unexpected.
Signed-off-by: Eric Mountain <eric.mountain@datadoghq.com>
Capabilities are serialised in VFS_CAP_REVISION_3 when an image is
built in a user-namespaced daemon, instead of VFS_CAP_REVISION_2.
This adds a test for this, though it's currently wired to fail if
the capabilities are serialised in VFS_CAP_REVISION_2 instead in this
situation, since this is unexpected.
Signed-off-by: Eric Mountain <eric.mountain@datadoghq.com>
Capabilities are serialised in VFS_CAP_REVISION_3 when an image is
built in a user-namespaced daemon, instead of VFS_CAP_REVISION_2.
This adds a test for this, though it's currently wired to fail if
the capabilities are serialised in VFS_CAP_REVISION_2 instead in this
situation, since this is unexpected.
Signed-off-by: Eric Mountain <eric.mountain@datadoghq.com>
Description
When images are built by a deamon running with user namespaces, extended attribute capabilities are saved in v3 format, thereby including the UID of the root user of the user namespace.
Running such images inside another runtime, either with no user-namespacing, or with a different user-namespace setup for the UID of the root user, the effective bit is ignored by
execve(2)
as the UID does not match.For images built with the userns feature to be portable across runtimes, we need capabilities to be saved in v2 format in the image layer archives.
Steps to reproduce the issue:
A reproducer can be found here.
Describe the results you received:
End of the reproducer output:
In the output above, the 2nd set of Cap* should match the first set.
execve(2)
has ignored the effective bit onsleep-test
in the 2nd case because the root UID stored in the extended attribute does not match the runtime.Describe the results you expected:
Expect to be able to run images built on user-namespaced environments in non-user-namespaced environments (or with a different user-namespace owner UID) and have the effective bit for capabilities honoured by
execve(2)
.Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version
:Output of
docker info
:This is for the non-user-namespaced configuration, however the user-namespaced configuration is identical, with
userns
added to the Security Options section:Additional environment details (AWS, VirtualBox, physical, etc.):
N/A
The text was updated successfully, but these errors were encountered: