1
0
mirror of https://github.com/docker/cli.git synced 2025-08-29 00:47:54 +03:00
Files
cli/opts/capabilities_test.go
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

120 lines
2.4 KiB
Go

package opts
import (
"strconv"
"testing"
"gotest.tools/v3/assert"
)
func TestNormalizeCapability(t *testing.T) {
tests := []struct{ in, out string }{
{in: "ALL", out: "ALL"},
{in: "FOO", out: "CAP_FOO"},
{in: "CAP_FOO", out: "CAP_FOO"},
{in: "CAPFOO", out: "CAP_CAPFOO"},
// case-insensitive handling
{in: "aLl", out: "ALL"},
{in: "foO", out: "CAP_FOO"},
{in: "cAp_foO", out: "CAP_FOO"},
// white space handling. strictly, these could be considered "invalid",
// but are a likely situation, so handling these for now.
{in: " ALL ", out: "ALL"},
{in: " FOO ", out: "CAP_FOO"},
{in: " CAP_FOO ", out: "CAP_FOO"},
{in: " ALL ", out: "ALL"},
{in: " FOO ", out: "CAP_FOO"},
{in: " CAP_FOO ", out: "CAP_FOO"},
// weird values: no validation takes place currently, so these
// are handled same as values above; we could consider not accepting
// these in future
{in: "SOME CAP", out: "CAP_SOME CAP"},
{in: "_FOO", out: "CAP__FOO"},
}
for _, tc := range tests {
tc := tc
t.Run(tc.in, func(t *testing.T) {
assert.Equal(t, NormalizeCapability(tc.in), tc.out)
})
}
}
func TestEffectiveCapAddCapDrop(t *testing.T) {
type caps struct {
add, drop []string
}
tests := []struct {
in, out caps
}{
{
in: caps{
add: []string{"one", "two"},
drop: []string{"one", "two"},
},
out: caps{
add: []string{"CAP_ONE", "CAP_TWO"},
},
},
{
in: caps{
add: []string{"CAP_ONE", "cap_one", "CAP_TWO"},
drop: []string{"one", "cap_two"},
},
out: caps{
add: []string{"CAP_ONE", "CAP_TWO"},
},
},
{
in: caps{
add: []string{"CAP_ONE", "CAP_TWO"},
drop: []string{"CAP_ONE", "CAP_THREE"},
},
out: caps{
add: []string{"CAP_ONE", "CAP_TWO"},
drop: []string{"CAP_THREE"},
},
},
{
in: caps{
add: []string{"ALL"},
drop: []string{"CAP_ONE", "CAP_TWO"},
},
out: caps{
add: []string{"ALL"},
drop: []string{"CAP_ONE", "CAP_TWO"},
},
},
{
in: caps{
add: []string{"ALL", "CAP_ONE"},
},
out: caps{
add: []string{"ALL"},
},
},
{
in: caps{
drop: []string{"ALL", "CAP_ONE"},
},
out: caps{
drop: []string{"ALL"},
},
},
}
for i, tc := range tests {
tc := tc
t.Run(strconv.Itoa(i), func(t *testing.T) {
add, drop := EffectiveCapAddCapDrop(tc.in.add, tc.in.drop)
assert.DeepEqual(t, add, tc.out.add)
assert.DeepEqual(t, drop, tc.out.drop)
})
}
}