Does anyone have objections to this? I'm good with any of them.

UX-wise, I like that option, so (name to be discussed);

--security-opt systempaths=unconfined

Would send the equivalent of --masked-paths=[]

Concern:

• systempaths=unconfined would disable all masked paths
• because of the above, doing the wrong thing ("just unmask the whole shebang) is easier than doing the right thing ("specify which paths you want to unmask")

I think it's important when dealing with security configuration to make "doing the right thing" easier than "doing the wrong thing".

So; do we also want to provide a more fine-grained approach on the CLI; an option to manually provide exactly which paths to mask/mark readonly?

If yes: that would raise the question #1347 (comment)

how would the CLI determine the default set of masked paths? (I don't think there's currently an endpoint that would allow querying the default set from the daemon, other than inspecting an already created container)

Approach could then be;

Implement a defaults endpoint for containers (I think that's useful for other purposes as well, such as showing defaults for flags/options; especially if those defaults are configurable on the daemon), for example;

• GET /v1.40/containers/-/defaults (- indenting as "no id" ? idk)
• GET /v1.40/containers/-/json (ugh .. the trailing /json sucks haha)

When creating a container;

1. Fetch the defaults
2. Patch the defaults with changes from the CLI (?) (---security-opt unconfined-paths=/proc,/sys)
3. Send the resulting masked-paths and readonly-paths over the API

@justincormack @jessfraz I know you're better at security than I am, so wondering what you think, or what suggestions you have 😅

Adding this to next week's maintainers meeting as well (this week didn't happen, due to many people travelling or at KubeCon)