Bug 466292
| Summary: | "sudo -l" segfaults | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Collier <imc> | ||||
| Component: | sudo | Assignee: | Daniel Kopeček <dkopecek> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9 | CC: | kzak, pvrabec | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-11-12 02:52:34 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Hmm, I can't reproduce it. It works for me. Reassigning to new sudo maintainer. Since I notice that section of parse.yacc mentions selinux, I guess it may help to know that /etc/selinux/config says: SELINUX=disabled SELINUXTYPE=targeted Works for me.
# yum install sudo
...
# rpm -q sudo
sudo-1.6.9p13-4.fc9.i386
# grep ^SELINUX /etc/selinux/config
SELINUX=disabled
SELINUXTYPE=targeted
# sudo -l
User root may run the following commands on this host:
(ALL) ALL
> sudo -l
[sudo] password for dkopecek:
...
Created attachment 321013 [details]
/etc/sudoers
Hmm, it's now working for me with the original /etc/sudoers but still
failing with the edited one. So I am attaching the /etc/sudoers which
definitely fails (maybe you will find a syntax error in it).
Still works...
# sudo -l
User root may run the following commands on this host:
(ALL) ALL
(root) /usr/local/sudo/bin/yum, /usr/local/sudo/bin/install, /usr/local/sudo/bin/update, /usr/local/sudo/bin/list
> sudo -l
User dkopecek may run the following commands on this host:
(root) /usr/local/sudo/bin/yum, /usr/local/sudo/bin/install, /usr/local/sudo/bin/update, /usr/local/sudo/bin/list
Perhaps this helps...
# chkconfig --list nscd
nscd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
$ sudo -l
Segmentation fault
# service nscd start
Starting nscd: [ OK ]
$ sudo -l
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for imc:
User imc may run the following commands on this host:
(ALL) ALL
(root) /usr/local/sudo/bin/yum, /usr/local/sudo/bin/install, /usr/local/sudo/bin/update, /usr/local/sudo/bin/list
# service nscd stop
Stopping nscd: [ OK ]
$ sudo -l
Segmentation fault
In addition:
$ egrep 'passwd|group' /etc/nsswitch.conf
passwd: compat
group: compat
netgroup: files nis
Sorry, I still can't reproduce it. It works for me with nscd started/stopped and with the same nssswitch.conf configuration. Could you please try to reproduce it on another machine using the same version of sudo, etc.? I have over 45 machines where it fails. About half of them used to be cloned FC4 systems (half a dozen i686, the rest x86_64) and were individually upgraded to F9. One has been upgraded from FC6. The rest are cloned from an x86_64 image that was upgraded from F7 to F9. I'm not sure what other information to collect for you - if you think of some, please let me know. I can run it under a debugger but I wouldn't know what I'm looking for so any hints there would be welcome. Which version of bison do you have installed? Do you have a machine with a clean F9 installation (not upgraded from previous releases)? It's now my belief that anywhere in parse.yacc where it mentions cm_list_len-1 without first checking the value of cm_list_len is a bug. If it doesn't crash then it just means you were lucky enough to have an accessible page of memory below the cm_list array. Try this: # yum install ElectricFence # LD_PRELOAD=/usr/lib64/libefence.so EF_PROTECT_BELOW=1 sudo -l Indeed. I'm working on a fix for this now. sudo-1.6.9p13-7.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/sudo-1.6.9p13-7.fc9 Could you please test the updated package? It should be available in updates-testing in a short while. sudo-1.6.9p13-7.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update sudo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9323 Oops - I was waiting for this to appear in updates-testing until I suddenly realised I should have been looking in updates-testing-newkey. So: sudo -l works now, so I guess this bug is fixed. On the other hand, the secure path change breaks our site's usage of sudo. But that is a discussion for bug 80215. sudo-1.6.9p13-7.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |
Version-Release number of selected component (if applicable): sudo-1.6.9p13-4.fc9 [both i386 and x86_64] How reproducible: Always Steps to Reproduce: 1. yum install sudo 2. sudo -l Actual results: Segmentation fault Expected results: Displays the list of commands I am allowed to execute. Additional info: This is using the /etc/sudoers file that came with the Fedora package mentioned above. (gdb) bt #0 0x00217743 in strlen () from /lib/libc.so.6 #1 0xb7f35a8e in estrdup (src=0x6d6d452c <Address 0x6d6d452c out of bounds>) at alloc.c:170 #2 0xb7f325dc in yyparse () at parse.yacc:573 #3 0xb7f27c17 in sudoers_lookup (pwflag=50) at parse.c:133 #4 0xb7f2a61f in main (argc=Cannot access memory at address 0x0 ) at sudo.c:297 (gdb) up #1 0xb7f35a8e in estrdup (src=0x6d6d452c <Address 0x6d6d452c out of bounds>) at alloc.c:170 170 size = strlen(src) + 1; (gdb) up #2 0xb7f325dc in yyparse () at parse.yacc:573 573 cm_list[cm_list_len].role = (gdb) print cm_list_len $1 = 0 That's why it crashed. How it came to execute this line with cm_list_len==0 I don't know, since I don't understand yacc.