Open Svintooo opened 5 months ago
Thanks. I don't think we have focused on WSL being 'supported' yet, so I've added the "enhancement" label as well. Firing up a Windows machine to see if I can reproduce.
Does this only happen with the --login
flag? (I.e. does a plain ./sudo echo hello
work?)
I managed to reproduce by upgrading my stretch
Debian WSL-installation to bookworm
, but in that scenario original sudo also didn't work (failing with an error about a pam session module not being found). A freshly installed Debian bookworm in WSL: everything seems fine.
So another question: what does original sudo print on your side?
Managed to reproduce! Very closely tied to the --login
flag indeed, so that should make it easy to track down the issue.
Tried it in a docker container, same thing happens, so does not seem tied to WSL.
I have the same issue on my PC installation of Arch Linux. I installed sudo-rs 0.2.2 from the AUR.
@JoelleJS Just to make sure: Did you fix the missing setuid/setgid on the sudo-rs binary? The AUR package currently have a bug so setuid/getuid will not be correct after install. https://aur.archlinux.org/packages/sudo-rs#comment-960169
@Svintooo Yes, I added the setuid
flag to the binary after installing. It is otherwise working and authenticating fine, I am only getting the error mentioned in the issue when using the --login
option.
Note: I've also noticed that in a fresh Arch-linux docker container, there is no PAM config for sudo, since there is no sudo in that docker. We should probably check with downstream packagers that they've thought of this.
For Arch this would mean that the AUR sudo-rs package has a dependency on sudo unless the appropriate PAM files in /etc/pam.d/
are (conditionally) installed. I'll also check if Debian/Fedora packages have this same issue; but it's separate from this one, and we should also mention this in the README and perhaps supply a default --- not that I expect anyone that wants to install sudo-rs to not have sudo installed, but it's strange to have this dependency.
I am not sure if missing PAM config for sudo
is related to the problem in this issue, since I experienced the issue while having standard sudo
installed. And standard sudo
did not have any problem with the --login
flag, only sudo-rs
had the problem.
I've located the issue to this line: https://github.com/memorysafety/sudo-rs/blob/ebd3e60024b88c4506da69b86a96a4ec694d3c04/src/sudo/pam.rs#L114
Since "sudo --login" starts a new login shell, a different PAM service name is used. This is done on purpose -- the system might have to do different session management for login sessions.
ArchLinux doesn't provide this "sudo-i" service so authentication fails.
Easy fix for Arch users:
sudo cp /etc/pam.d/sudo /etc/pam.d/sudo-i
After that, sudo --login
works as expected.
I guess this is not a problem with original sudo because that is likely compiled by the package maintainer with the HAVE_PAM_LOGIN
flag unset:
https://github.com/sudo-project/sudo/blob/b6175b78ad1c4c9535cad48cb76addf53352a28f/plugins/sudoers/defaults.c#L554-L560
To make sudo-rs the same, the AUR package maintainer can patch the above line in sudo-rs source code so the service_name is always "sudo"
on Arch Linux; or upon installing the sudo-rs package, also create the appropriate sudo-i
PAM configuration.
Of course in the precompiled binaries we provide, we had to pick one and I think we went with sudo-i
since that was what the standard was on the major Linux distributions (cc @rnijveld), so we can't really fix it there. But we must expand the README to mention the PAM configuration that has to be present.
Suggestion: Would it be possible to print a more descriptive error message when this issue happens? To just report that the login failed feels misleading.
As an example, sudo-rs has a great error message (IMO) when setuid/setgid is not set for the binary. Maybe something along those lines?
Good suggestion, let's create another issue for that.
During my investigation here, I've also noticed original sudo sometimes printing uninformative error messages. Whether it is possible, I don't know -- this also requires the cooperation of PAM to give us helpful feedback. I think sudo-rs
will pass PAM errors simply along as it receives them. But we can always investigate this for the next Milestone.
I just want to say thank you for a great experience in reporting this issue. The response this got has been wonderful. Sorry if I did anything that created unnecessary problems.
The biggest issue I see is that a missing service configuration could be a valid configuration, as PAM automatically falls back to the global PAM configuration in /etc/pam.conf
(or whatever other default path was chosen at compile time) and that could be intentional. Apparently this configuration automatically causes an authentication failure on Arch Linux. I'm not sure if there is a way around this to make the error messages more informative. Unfortunately its a little hard to read the intent of the system administrator based on how PAM is configured. Did they intent to not allow login sessions via sudo, or did they forget to configure PAM for login sessions.
I think the best thing we could do is provide an example PAM configuration with our packages and include instructions for setting them up. Then leave it up to packagers of sudo to provide a configuration suitable for their specific distribution.
One more thing we could do is to add build time configuration to allow changing the PAM service names for both login sessions and normal sessions at compile time, to give downstream maintainers a little more freedom (i.e. change the names of the services to sudo-rs
and sudo-rs-i
, or using the sudo
service for both login and non-login sessions) without having to patch sudo-rs right away.
Thanks to your help, I am adding the changes here in PKGBUILD. And do sudo-rs -i test.
❯ sudo-rs -i
arch# whoami
root
arch# exit
❯ sudo-rs --login
arch# whoami
root
arch#
Describe the bug Whenever I try to use the
--login
option I instantly get an AuthError. No password prompt is shown. This is on Arch Linux on Windows Subsystem for Linux on Windows 11.To Reproduce
Expected behavior Either receive a password prompt, OR execute
echo hello
.Environment:
sudo-rs
commit hash:f317145
(Version 0.2.2) (I also tried with a manual compile of master (ebd3e60
) and got the same error.Additional context No additional context.