https://bugs.kde.org/show_bug.cgi?id=521012
Mark Cockram <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Mark Cockram <[email protected]> --- # Upstream filing drafts — anonymous "[sudo: authenticate] Password:" askpass dialog Research date: 2026-09-09. Active `sudo` on this host is **sudo-rs 0.2.13** (update-alternatives → /usr/lib/cargo/bin/sudo); classic sudo 1.9.17p2 is installed but inactive. ## Facts - ksshaskpass (`src/main.cpp`, `src/prompt.cpp`): the prompt is the single positional arg; `parsePrompt()` matches openssh/git patterns only, `[sudo: authenticate] Password:` matches none and is shown verbatim. No /proc reads, no extra argv, only `SSH_ASKPASS_PROMPT` (dialog *type*). Title "Enter SSH Credentials" hardcoded by commit b7a473e (Mar 2024); commit ed17c44 (Jul 2026, unreleased) drops it. - sudo-rs `src/pam/askpass.rs::handle_child`: `Command::new(program).arg(prompt)` — one argv, env inherited unchanged. Prefix built in `src/pam/converse.rs`: `"[{converser_name}: {prompt}] {msg}"` with both literals hardcoded ("sudo", "authenticate"); `msg` is PAM's "Password: ". `SUDO_COMMAND` is only set in the executed command's env, never for the askpass child. - Classic sudo: `sudo_askpass()` execl(askpass, askpass, prompt) — same; prompt escapes only `%h %H %p %u %U %%`. ## Existing reports - bugs.kde.org **#521012** — "Enter SSH Credentials" dialog should specify what app or service is triggering it — CONFIRMED wishlist (2026-06-03). Exact duplicate → comment, don't file. - sudo-rs #1590 (expose prompt text to PAM via SUDO_PROMPT), #1267 (implement passprompt) — adjacent, not duplicates. No issue asks to expose the target command to the askpass helper → new issue is safe. ## Draft A — comment on bugs.kde.org #521012 Confirmed this is still open in the current ksshaskpass (checked `main.cpp`/`prompt.cpp` on invent.kde.org master as of 2026-09). The prompt argv ksshaskpass receives carries no caller identity — that's inherent to the askpass protocol (both classic sudo and sudo-rs pass a single string argv and nothing else) — so a generic fix belongs here, not in every caller. Minimal proposal: ksshaskpass already knows its own PID, so `getppid()` gives the direct parent (the process that exec'd it — sudo, ssh, ssh-add, etc.). Before showing the dialog: - Read `/proc/<getppid()>/cmdline` (NUL-separated argv) and show it as a small collapsible "Details" section, not in the main prompt text, so nothing breaks for scripted callers that only expect the password back on stdout. - Optionally also read `/proc/<getppid()>/cgroup` to surface the owning systemd unit name (distinguishes a background timer from an interactive shell). - Treat both reads as best-effort: `/proc` may be restricted (hardened kernels, containers) or the PID may already be gone — fall back silently to today's behavior. This needs no changes to sudo, sudo-rs, ssh, or the askpass invocation protocol — it's entirely local to ksshaskpass. ## Draft B — new issue on trifectatechfoundation/sudo-rs Title: askpass: expose the command being authorized to the askpass helper **Problem**: When `sudo -A` invokes an askpass helper, the helper receives only the PAM prompt text (e.g. `[sudo: authenticate] Password: `) as its single argv, with no indication of which command sudo is about to run. On KDE this surfaces as ksshaskpass's dialog titled "Enter SSH Credentials" with no further context — the user cannot tell what is asking for root (bugs.kde.org #521012 is the ksshaskpass-side wishlist for the same gap). Helpers that want to show this can read `/proc/<getppid()>/cmdline` themselves (the askpass child's parent is the sudo-rs process, whose argv contains the target command), but that is fragile and undocumented. **Minimal proposal**: pass the resolved command (`ctx.command`, already formatted for `SUDO_COMMAND`) to the askpass helper as an opt-in signal — e.g. set `SUDO_COMMAND` in the askpass child's environment (mirroring what is already exported to the eventual target-command environment) before `exec`. Backward compatible (existing helpers ignore unknown env vars), no change to the argv/stdout protocol. Happy to open a PR if this direction is acceptable. -- You are receiving this mail because: You are watching all bug changes.
