docs: explain install-time UID binding under no multi-user support#568
Conversation
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟡 NEEDS ATTENTION
This PR adds useful detail to the No multi-user support limitation, explaining the install-time UID binding mechanism. Two issues were found in the changed lines: one confirmed and one likely.
| missing — typically headless or server installs — the daemon currently crashes | ||
| instead of degrading gracefully. We are working on a fix; in the meantime, the | ||
| workaround is to install and set up D-Bus and either GNOME Keyring or KWallet. | ||
| - **No automatic restart after a `dockerd` restart.** When the Docker Engine is |
There was a problem hiding this comment.
[MEDIUM] Silent removal of documented limitation may mislead users
The **No automatic restart after a \dockerd` restart.**bullet — which previously documented that the Secrets Engine daemon must be manually restarted viasystemctl --user restart docker-secrets-engine` after an engine restart — has been silently deleted with no explanation.
If this limitation was fixed by other changes, a brief note (e.g., "this limitation was resolved in …") would reassure users. If the limitation still exists, removing it leaves users without the workaround and could cause them to believe injection continues automatically after a dockerd restart. Either way, a silent removal of an operational known-issue entry is misleading for anyone consulting this section for troubleshooting.
Consider either:
- Adding a note that this limitation was resolved, or
- Keeping the bullet (or a condensed version) if it still applies.
| reliably route a resolution request to the right user's daemon. As a | ||
| consequence, the user the daemon talks to is fixed at install time: the | ||
| package's post-install script records the installing user's UID (resolved from | ||
| `$SUDO_UID`, i.e. the user who ran `sudo apt install` / `sudo dnf install`) |
There was a problem hiding this comment.
[MEDIUM] $SUDO_UID edge case insufficiently documented for automated installs
The new text describes the happy path — sudo apt install / sudo dnf install run interactively by a user — but $SUDO_UID is unset whenever the package is installed as root directly (e.g., apt install in a Dockerfile, an Ansible playbook, a CI/CD pipeline, or any tool that invokes the package manager as root without sudo). In those cases the post-install script silently falls through to the "integration stays inert" path, with no visible indication to the operator of why.
The fallback sentence is present but phrased passively; it doesn't call out that automated/root installs are the primary trigger. Consider adding a parenthetical such as:
(This includes installs run directly as root, e.g., in CI/CD or configuration management —
$SUDO_UIDis only set when usingsudointeractively.)
3 participants
No description provided.