Skip to content

prune commands : make sure label filters are considered#21

Merged
tiborvass merged 1 commit into
docker:masterfrom
aduermael:prune-security
May 17, 2017
Merged

prune commands : make sure label filters are considered#21
tiborvass merged 1 commit into
docker:masterfrom
aduermael:prune-security

Conversation

@aduermael
Copy link
Copy Markdown
Contributor

@aduermael aduermael commented May 2, 2017

Fixes #17

Related to moby/moby#33023

Checking server API version is at least 1.29 to accept prune commands with label filters.

Signed-off-by: Adrien Duermael adrien@duermael.com

Comment thread cli/command/utils.go Outdated
pruneFilters.Add(parts[0], parts[1])
}

// Server APIs older than 1.29 will just ignore label filters.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel we should do that server side though (the cli should be as dumb as possible)
cc @thaJeztah @dnephin

Copy link
Copy Markdown
Contributor

@dnephin dnephin May 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would be more correct, but the problem is that the issue is with old servers, so it's hard to fix now.

The server should actually already error with it receives invalid filters. I'm not sure why it isn't.

We already do something like this on the client to hide flags based on version. This is just a little more fine grained. If we do need this we should find a way to do that is easily extend as more fields are added to labels.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vdemeester @dnephin is right. This client-side fix fixes it for older daemons. I have a moby/moby PR that is almost ready, fixing it server side (returning error for unknown prune filters).
It is gonna be part of 17.06 as 17.05 is about to get released, and we still have to design and discuss a part of this server-side fix. I am having troubles with docker system prune --filter ... as the CLI, for system prune, calls container prune, volume prune, image prune and network prune passing the same filters to all of them... so my to-be PR is currently braking because of this.
Thanks for reading.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gdevillele yep, I did mis-understand the fix at first 😅.

We might (or should have) validates filters by version (for any api endpoint that supports them) in docker/moby 😓

Comment thread cli/command/utils.go Outdated

import (
"bufio"
"context"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are still using golang.org/x/net/context

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on if we support go 1.6 for docker/cli or not, it's no big deal in the usage of it (as the interface is the same)

Comment thread cli/command/utils.go Outdated
// would just remove all stopped containers without considering the label
// The remote API should reject requests using unknown filters.
if pruneFilters.Get("label") != nil {
serverVersion, err := dockerCli.Client().ServerVersion(context.Background())
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API version should already be available as dockerCli.Client().ClientVersion() which is set by querying the server API version.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnephin

// ClientVersion returns the version string associated with this instance of the Client

Are you sure? What's important is to detect the version server side.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup,

cli/cli/command/cli.go

Lines 200 to 203 in 0a61397

// if server version is lower than the current cli, downgrade
if versions.LessThan(ping.APIVersion, cli.client.ClientVersion()) {
cli.client.UpdateClientVersion(ping.APIVersion)
}
sets the client version to the server version if the server version is lower.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnephin oh! good to know! thanks, I'll update this part

Copy link
Copy Markdown
Contributor

@gdevillele gdevillele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Copy Markdown
Member

Do we still want this change? Daemon side validation was added in moby/moby#33023. "label" filtering was added in docker 17.05 through moby/moby#30740 (which is an edge release, so not supported after 17.06 is released), and the --filter option for until was added in 17.04 (moby/moby#29226), also an edge release, and now EOL. So situations where the filter would be ignored would only be if someone ran an 17.04 or 17.05 client against an older daemon

@aduermael
Copy link
Copy Markdown
Contributor Author

So situations where the filter would be ignored would only be if someone ran an 17.04 or 17.05 client against an older daemon

That happens to me sometimes, I still have a few older daemons here and there... I guess it won't happen very often, and I would be ok to drop this if the command was not prune. But in that case consequences can be quite bad...

@thaJeztah
Copy link
Copy Markdown
Member

Actually (we were discussing on slack); it looks like the --filter flag itself does not have an API version annotation. That should added, so that when talking to an older (17.03, which is "stable") daemon version, an error is shown

Hold on, I'll add an example

Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left an example (double check, but I think docker 17.04 was API version 1.28)

Comment thread cli/command/system/prune.go Outdated
flags.BoolVarP(&opts.force, "force", "f", false, "Do not prompt for confirmation")
flags.BoolVarP(&opts.all, "all", "a", false, "Remove all unused images not just dangling ones")
flags.Var(&opts.filter, "filter", "Provide filter values (e.g. 'until=<timestamp>')")
flags.Var(&opts.filter, "filter", "Provide filter values (e.g. 'label=<key>=<value>')")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have an annotation (like in cli/command/stack/deploy.go#L46)

flags.SetAnnotation("filter", "version", []string{"1.28"})

Same for the other prune --filter flags

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh! I did't know about this!
I'll update the PR then, it's much simpler this way.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also see see moby/moby#30187 and moby/moby#30186 for some more info about that :)

@thaJeztah thaJeztah added this to the 17.06.0 milestone May 16, 2017
@thaJeztah
Copy link
Copy Markdown
Member

ping @aduermael looks like this needs a rebase (also can you address my comment, so that we can get this in for 17.06?)

@gdevillele gdevillele force-pushed the prune-security branch 2 times, most recently from dfa4003 to 86d9eac Compare May 17, 2017 19:06
Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changes LGTM; can you squash the commits?

…i v1.28) and newer

Signed-off-by: Gaetan de Villele <gdevillele@gmail.com>
@tiborvass
Copy link
Copy Markdown
Collaborator

LGTM

@tiborvass tiborvass merged commit 63ecaf1 into docker:master May 17, 2017
nobiit pushed a commit to nobidev/docker-cli that referenced this pull request Nov 19, 2025
Vendoring libnetwork b54433f6459b84eae77892d0d359c1bafb133529
nobiit pushed a commit to nobidev/docker-cli that referenced this pull request Nov 19, 2025
* Prefixes documentation files per component

Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>

* Remove reliance on basename

Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
(cherry picked from commit 24e443c109ae5e133f1b20e6c4f9a17126767c71)
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants