Sudo does not appear to work (at all) when emerged on a system that was installed using the stage3 i686 tarball. sudo <anything> results in a permission denied error, saying that it cannot read /etc/sudoers. We have tried numerous debugging steps, including building static binaries on other machines and copying them over. Solar has figured out the bug is related to the egid and has a workaround patch for it, but it does not answer the question of why it occurs in the first place. Steps to reproduce: 1) install a gentoo system using the 2005.1 stage3 i686 stageball. 2) emerge sudo 3) try 'sudo su -' as root or any other sudo command as any user workaround patch is available at d.g.o/~solar/patches/sudo-seteuid.patch, but this doesn't properly solve the problem -- merely forcibly changes permissions.
What is: ls -l /etc/sudoers And do you have /etc/sudoers setup correctly? Also, what's in: /etc/pam.d/sudo?
the permissions on /etc/sudoers and /usr/bin/sudo are identical to other machines with working copies of sudo. To answer the specific question: klieber@jaguar ~ $ ls -alh /etc/sudoers -r--r----- 1 root root 1.7K Aug 6 12:34 /etc/sudoers klieber@jaguar ~ $ cat /etc/pam.d/sudo # File autogenerated by pamd_mimic_system in pam eclass auth include system-auth account include system-auth password include system-auth session include system-auth We have tried compiling a version of sudo without PAM support....same issue.
Try: auth required pam_unix.so account required pam_unix.so
So then I assume you have suid set on sudo?
jaguar bin # cat /etc/pam.d/sudo # File autogenerated by pamd_mimic_system in pam eclass #auth include system-auth #account include system-auth #password include system-auth #session include system-auth auth required pam_unix.so account required pam_unix.so jaguar bin # sudo su - sudo: can't open /etc/sudoers: Permission denied
jaguar bin # ls -alh /usr/bin/sudo ---s--x--x 1 root root 96K Aug 6 15:55 /usr/bin/sudo
Very odd. You have my same set up to the 'T'.
Just out of curiosity, what is your /etc/sudoers? (You can attach it if you want)
it's the default configuration file included with the sudo ebuild. I uncommented one line to let wheel users use any command without a password, but the file is otherwise identical.
Try it with the line that allows for wheel users, but they have to enter the password, and recomment the other one. Maybe this will narrow things down.
done -- same results.
Created attachment 65258 [details] strace of sudo failure
same error on vanilla 2.6.11.10 kernel / pentium3 800 / reiserfs glibc_problem++
+1 on amd64 linux32 chroot, 2.6.12-gentoo-r7 It doesn't seem to be sse-related as it's reproduceable on athlon-tbirds, too. While this seems to be present also with statically-linked programs, I'm tempted to say "there's nothing like a static executable when glibc is in the way".
FWIW, it's not a problem with just sudoers so it's not a permission problem at all.. the testcase proposed by r2d2 shown that *whichever* file you try to open with setresgid/setresuid sets is just the same result.
No changes with: glibc-2.3.4.whatever from stage glibc-2.3.5 -nptl glibc-2.3.5 +nptl problem seems to be with setresuid() ... i'm thinking if sudo can work without such a call at all (there's an option to disable it in the ./configure).
I've noticed that in your code snippets you are running as root. What happens when you run sudo as a regular user?
Same error (access denied).
Did you happen to edit the file without using visudo or something like that?
I edited it with nano, but all I changed was uncommenting the same line that klieber said he uncommented in comment 9.
I've done some googling, and have the following questions/suggestions: 1. You wouldn't happen to have your /etc directory remotely mounted or anything like that? 2. What are the permissions on '/'? 3. Have you tried linking sudo staticly?
Ok, just for clarity, here is how we produce the bug: Clean install with a 2005.1 i686 stage3 tarball emerge sudo visudo to give wheel group access try to 'sudo anything' as a wheel user Perm denied..
You can also reproduce by running 'sudo anything' as root with the default /etc/sudoers.
I think I have this fixed in the latest tarball on poseidon... at least, r2d2's test case didn't cause a failure... I think this is ready to go
Andy is right, I looked at the root directory to see the permissions and was 700... set 775 and now it works as a charm.
Yay! That's good enough for me! ;)
This was fixed before release. In the future, there is always a pre-release bug for each release where these things should be commented on before they hit the wild. Thanks for catching this before it hit the mirrors. =]
I have the same issue here. When I want to sudo, i got 'sudo: uid XXXX does not exist in the passwd file!', which is indeed correct. I'm using ldap for user managment but it suddendly stops working when I updated sudo.
This is not the same issue at all, and it actually a sudo bug, not a release bug. Please file a new bug regarding sudo and assign it to the proper people, or leave the assignment up to bug-wranglers.
*** Bug 107912 has been marked as a duplicate of this bug. ***
