On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:That may be ok though. Assume the host created a container with
Quoting Stefan Berger (stefanb@xxxxxxxxxxxxxxxxxx):No, I don't have a patch. It may not be possible to implement it.
If all extendedRight, I missed that in your original email when I saw it this morning.
attributes were to support this model, maybe the 'uid' could be
associated with the 'name' of the xattr rather than its 'value' (not
sure whether that's possible).
It's not what my patch does, but it's an interesting idea. Do you have
a patch to that effect? We might even be able to generalize that to
The xattr_handler's take the name of the xattr as input to get().
100000 as the uid for root, which created a container with 130000 as
uid for root. If root in the nested container tries to read the
xattr, the kernel can check for security.foo[130000] first, then
security.foo[100000], then security.foo. Or, it can do a listxattr
and look for those. Am I overlooking one?
So one could try to encode the mapped uid in the name. However, thatI thought that's exactly what you were suggesting in your original
email? "security.capability[uid=2000]"
could lead to problems with stale xattrs in a shared filesystem overHm. Yeah. But really how many setups are there like that? I.e. if
time unless one could limit the number of xattrs with the same
prefix, e.g., security.capability*. So I doubt that it would work.
you launch a regular docker or lxd container, the image doesn't do a
bind mount of a shared image, it layers something above it or does a
copy. What setups do you know of where multiple containers in different
user namespaces mount the same filesystem shared and writeable?
Otherwise it would be good if the value was wrapped in a data
structure use by all xattrs, but that doesn't seem to be the case,
either. So I guess we have to go into each type of value structure
and add a uid field there.
namespace any security.* xattrs. Wouldn't be automatically enabled
for anything but ima and capabilities, but we could make the infrastructure
generic and re-usable.