Aleksa Sarai
Aleksa Sarai
@spawnflagger > There is a fundamental difference between install time and run time. During install time, it's the root user that is modifying the system, and it's necessary (for most...
@aauren I would argue that having access to the *output* profile (which has already been loaded by Docker) will not be as useful as having access to the *input* profile...
I would definitely recommend writing the wrapper. I'm working on the patch at the moment and you immediately hit problems because the `--security-opt seccomp` and `--security-opt apparmor` are completely different...
@dannysauer > There's actually no problem at all writing to /etc/apparmor.d on either system at the time of installation/upgrade. This doesn't affect Docker's apparmor profiles. Docker loads them directly from...
> There's really no reason for the profile to be written anywhere at runtime, since it's static for the lifetime of a given docker version. #41442 makes the profile be...
@Crypto-Spartan The complete apparmor profile is defined in [profiles/apparmor/template.go](https://raw.githubusercontent.com/moby/moby/master/profiles/apparmor/template.go), it's just written using Go's `text/template`. We could make a script to generate it (like we do for seccomp) but the...
> Maybe this could be an object like: > > ``` > "mountExtensions": { > "idmap": { > "modes": ["sameAsUserns", "arbitrary"], > "filesystemTypes": ["ext4", "tmpfs", "foobarfs"], > "supportsBind": true >...
I think having a list of supported (or explicitly unsupported) filesystems would be a good idea. Now that I think about it, since runc will not release a version with...
> besides I don't know how you plan to detect idmap mount support at runtime That isn't my proposal -- the plan is to provide a list of filesystems that...
The runtime-cli specification was a proposal to define a CLI interface that all runtimes must support. The operations you mention are all _operations_ that could be implemented as a CLI,...