DockerCLI/opts/capabilities_test.go

119 lines
2.4 KiB
Go
Raw Normal View History

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-08-25 07:03:06 -04:00
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)
})
}
}