Open lucab opened 8 years ago
Reference https://github.com/coreos/rkt/issues/2996.
/cc @euank
At first blush this sounds awkward because it seems like something that should really be handled in the filesystem layer; but I accept that doesn't facilitate all these use cases. This seems okay to me, though would be nice to get another opinion.
@vbatts thoughts?
i like the concepts. IIRC, i was in favor of a blacklist path approach in addition to pathWhitelist
and ACE currently has. But whether masking the files instead of removing them? I'm not sure which would be better.
Regardless, for both of these features, I'd be interested to see how the wording will be enforced for implementations. Because if a path is masked or made read-only, presumably by a bind mount or similar, then a container would have to ensure not having umount()
capability otherwise it is pointless (Granted that implies CAP_SYS_ADMIN
, but still)
Also, does masked imply that they can't see the path? or that they cannot read from the path? I'm not really clear
i like the concepts. IIRC, i was in favor of a blacklist path approach in addition to
pathWhitelist
and ACE currently has. But whether masking the files instead of removing them? I'm not sure which would be better.
AFAIK the files we want to blacklist here are files that won't be present in the image (/proc/something
or /sys/fs/something
) so I don't think it should be related to pathWhitelist
or an eventual pathBlacklist
.
Also, does masked imply that they can't see the path? or that they cannot read from the path? I'm not really clear
systemd implementation for reference: https://github.com/systemd/systemd/pull/3685
This is a request for two new isolators, useful for making paths unreachable or read-only. This follows concepts already present in OCI config and in rkt contaiment.
Example:
Up for discussion: better isolators category/name?