Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SUDO_PROMPT implementation request #842

Open
id3v1669 opened this issue Apr 21, 2024 · 4 comments
Open

SUDO_PROMPT implementation request #842

id3v1669 opened this issue Apr 21, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@id3v1669
Copy link

I've seen in #129 that creation of this functionality is in Doubtful section, but asking for its implementation due to this issue.

@id3v1669 id3v1669 added the enhancement New feature or request label Apr 21, 2024
@squell
Copy link
Member

squell commented Apr 22, 2024

If I understand that issue correcty, it is enough to support -p "" to disable the prompt (although it's just as easy to support any other fixed string consisting of printable characters), and we don't need to add all the % expansions that c-sudo does. The interplay between the prompt and the -S option does sound like it's not unreasonable to allow some control over it.

Of course we should then also add the passprompt_override sudoers setting.

@squell
Copy link
Member

squell commented Apr 22, 2024

Note that that sudo-rs does indeed use stderr if -S is used, as c-sudo does.

@rnijveld
Copy link
Collaborator

The reason for not implementing this previously was that we don't necessarily have a password prompt, given that such prompts are being generated by PAM. You could have a system where asking for input could mean entering any kind of information, some other piece of information such as a username or email address, or more likely something like a pin, or some security or TOTP code. PAM modules could even just output a URL and hang until you visit that URL on some other device and do some authentication ritual over there.

Sudo works around this for PAM authentication by using a regex for matching the password prompt and then replacing that prompt with the one provided via -p or SUDO_PROMPT, which at least to me feels very fragile. But I'd also consider such a feature to allow misleading the user into inputting something that they did not intent to input at all (and probably confusing them as to why that piece of information didn't work when they were supposed to enter their password). And (with the -S flag set), sudo might still output stuff from any number of PAM modules to stderr anyway even with the SUDO_PROMPT set to a specific value.

For the Veracrypt GUI, I think they should really be implementing this using something like pkexec, which is intended to be used in a GUI context and doesn't touch stdout/err/in if in the right context, instead of relying on parsing CLI output based on very specific behavior. If the worry is that some weird input could be given via SUDO_PROMPT, why is that environment value even passed at all? Alternatively, it might be better to open a PTY at the very least, to prevent having to multiplex everything through stderr?

@LeChatP
Copy link

LeChatP commented May 20, 2024

Ansible uses a pseudorandomly generated prompt to ensure the terminal prompts for the password. The PAM default prompt is "Password:" which could be wrongly matched with many other stdout strings. I understand it isn't a great solution, but adding a mandatory way to deactivate it by default could solve the misleading issue. And so, Ansible and VeraCrypt users could use sudo-rs by doing an additional configuration step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants