Skip to content

Use user data path for plugin discovery in rootless mode#44733

Merged
neersighted merged 2 commits intomoby:masterfrom
jg-public:fix-rootless-specspaths--T43111
Jan 10, 2023
Merged

Use user data path for plugin discovery in rootless mode#44733
neersighted merged 2 commits intomoby:masterfrom
jg-public:fix-rootless-specspaths--T43111

Conversation

@jg-public
Copy link
Contributor

@jg-public jg-public commented Jan 2, 2023

Signed-off-by: Jan Garcia github-public@n-garcia.com

fixes #43111

- What I did

We now dynamically determine the plugins path when running in rootless mode.

- How I did it

Introduce a new function, plugins.SpecsPaths which returns $XDG_DATA_HOME/.local/share/docker/plugins
on Unix in rootless mode and specsPaths otherwise.

- How to verify it

You can test this by running dockerd in rootless mode while /etc/docker is not accessible by the user.
Without this patch, creating volumes will fail. With this patch creating volumes works.

- Description for the changelog

Use user data path for plugin discovery in rootless mode

Copy link
Contributor

@vvoland vvoland left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution! Looks good to me, but I left one comment regarding mutating the global variable.

Comment on lines +13 to +19
// ConfigureSpecsPaths configures plugins.specsPaths depending on if the daemon
// is running in rootless mode or not. On Windows, it is a no-op.
func ConfigureSpecsPaths() {
if rootless.RunningWithRootlessKit() {
dataHome, err := homedir.GetDataHome()
if err == nil {
specsPaths = []string{filepath.Join(dataHome, "docker/plugins")}
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally I would prefer to avoid functions that mutate global variables and depend on being called in a specific time and place.
I think it would be better to change specsPaths into a function returning paths, which would be defined differently in each discovery_<platform>.go. This way we don't have any global mutable variable and don't need to worry about calling the ConfigureSpecsPaths.
What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, will do

Copy link
Member

@thaJeztah thaJeztah Jan 2, 2023

Choose a reason for hiding this comment

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

Ah, yes, was thinking along the same lines as well; was also wondering; would it do any harm to unconditionally append homedir.GetDataHome() to the list of paths to look in? (if the XDG_XXXvar is set) Perhaps needs async.Onceto resolve the path once (if there's nothing like that yet), but then aspecPaths()` function could return the lists of paths to look for.

Copy link
Member

Choose a reason for hiding this comment

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

^^ I didn't dig into all code-paths though, so be sure to look if that idea works 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I introduced func SpecsPaths() []string while keeping specsPaths around to avoid a large diff in the Unit-Tests.

would it do any harm to unconditionally append homedir.GetDataHome() to the list of paths to look in?

Right now the user can use his own plugins without being affected by plugins installed in the host system.
If we add $XDG_DATA_HOME/.local/share/docker/plugins to SpecsPaths unconditionally, the user no longer has this option

Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

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

Thanks

@jg-public
Copy link
Contributor Author

See https://github.com/moby/moby/actions/runs/3828112441/jobs/6514666086

These files import internal code: (either directly or indirectly)

  • pkg/plugins/discovery_unix.go imports github.com/docker/docker/rootless

Code in ./pkg/* is not allowed to reference code not in ./pkg/*.
I suggest to move the directory ./rootless to ./pkg/rootless.
What do you think?

@AkihiroSuda
Copy link
Member

./rootless to ./pkg/rootless

SGTM

@jg-public jg-public requested a review from vvoland January 4, 2023 13:49
Copy link
Member

@neersighted neersighted left a comment

Choose a reason for hiding this comment

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

Slightly tangential to this PR, but I wonder if the homedir package should fall back to the starting directory from the passwd if HOME is not found in the environment. Comparison to other tools (e.g. Git, GnuPG, other well-known Unix software) would be interesting.

@jg-public
Copy link
Contributor Author

jg-public commented Jan 9, 2023

Slightly tangential to this PR, but I wonder if the homedir package should fall back to the starting directory from the passwd if HOME is not found in the environment. Comparison to other tools (e.g. Git, GnuPG, other well-known Unix software) would be interesting.

Doing so too is a good idea 👍 but I would not change this behavior in this PR


Checks fail because checks fail in the master too.
Is there anything I can do now to move this PR forward?

@neersighted
Copy link
Member

neersighted commented Jan 9, 2023

The failed check on master is a Jenkins alt-arch issues; the failure here is because of a stale branch. Please rebase onto master.

I'm ready to give this a LGTM; I have two slight objections but I believe they can be follow-ups if you are willing:

  • I'd like to see the pw_dir fallback.
  • I'd like to explore dropping the globalSpecPaths global mutation and instead inject a function that returns paths into the registry object.

Signed-off-by: Jan Garcia <github-public@n-garcia.com>
Signed-off-by: Jan Garcia <github-public@n-garcia.com>
@jg-public
Copy link
Contributor Author

Thank you, I rebased the branch as requested.

I'll create two follow-up PRs for

  1. the pw_dir fallback
  2. replace globalSpecPaths by a function in LocalRegistry

@neersighted
Copy link
Member

@AkihiroSuda I see you added the cherry-pick label; I'm assuming you think we should include this in the 23.0 branch, but not the 20.10 branch?

@AkihiroSuda
Copy link
Member

@AkihiroSuda I see you added the cherry-pick label; I'm assuming you think we should include this in the 23.0 branch, but not the 20.10 branch?

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Rootless docker - plugin discovery uses wrong path

5 participants