Commit Graph

2 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 23660be600
Service cap-add/cap-drop: add special "RESET" value
This implements a special "RESET" value that can be used to reset the
list of capabilities to add/drop when updating a service.

Given the following service;

| CapDrop        | CapAdd        |
| -------------- | ------------- |
| CAP_SOME_CAP   |               |

When updating the service, and applying `--cap-drop RESET`, the "drop" list
is reset to its default:

| CapDrop        | CapAdd        |
| -------------- | ------------- |
|                |               |

When updating the service, and applying `--cap-drop RESET`, combined with
`--cap-add CAP_SOME_CAP` and `--cap-drop CAP_SOME_OTHER_CAP`:

| CapDrop        | CapAdd        |
| -------------- | ------------- |
| CAP_FOO_CAP    | CAP_SOME_CAP  |

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-09-10 11:14:38 +02:00
Sebastiaan van Stijn 190c64b415
Service cap-add/cap-drop: improve handling of combinations and special "ALL" value
When creating and updating services, we need to avoid unneeded service churn.

The interaction of separate lists to "add" and "drop" capabilities, a special
("ALL") capability, as well as a "relaxed" format for accepted capabilities
(case-insensitive, `CAP_` prefix optional) make this rather involved.

This patch updates how we handle `--cap-add` / `--cap-drop` when  _creating_ as
well as _updating_, with the following rules/assumptions applied:

- both existing (service spec) and new (values passed through flags or in
  the compose-file) are normalized and de-duplicated before use.
- the special "ALL" capability is equivalent to "all capabilities" and taken
  into account when normalizing capabilities. Combining "ALL" capabilities
  and other capabilities is therefore equivalent to just specifying "ALL".
- adding capabilities takes precedence over dropping, which means that if
  a capability is both set to be "dropped" and to be "added", it is removed
  from the list to "drop".
- the final lists should be sorted and normalized to reduce service churn
- no validation of capabilities is handled by the client. Validation is
  delegated to the daemon/server.

When deploying a service using a docker-compose file, the docker-compose file
is *mostly* handled as being "declarative". However, many of the issues outlined
above also apply to compose-files, so similar handling is applied to compose
files as well to prevent service churn.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-09-08 14:38:35 +02:00