|
Bugzilla – Full Text Bug Listing |
| Summary: | gnomesu hangs while pressing cancel button on authentication (gnomesu-pam-backend) | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Daniel Gollub <dgollub> |
| Component: | GNOME | Assignee: | Dan Winship <danw> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | hpj, meissner |
| Version: | Beta 5 | ||
| Target Milestone: | Beta 6 | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Could not duplicate this. How are you launching gnomesu? Also libgnomesu in beta 4.2 was 1.0.0-14 for me, are you certain this in beta 5? check if the gnomesu-pam-backend is already runnig. you cannot reproduce this problem when gnomesu-pam-backend is already runnig. gnomesu-pam-backend have to be started by gnomesu. BTW: i can reproduce this problem on 10.0 :( jpr@zugzwang:~> ps ax | grep gnomesu 10350 pts/9 S+ 0:00 grep gnomesu jpr@zugzwang:~> gnomesu jpr@zugzwang:~> ps ax | grep gnomesu 10358 pts/9 S+ 0:00 grep gnomesu jpr@zugzwang:~ The gnomesu was cancelled in this case. Is there anything else about your setup you can think of? maybe another service is detected bei libgnomesu. do you need the backtrace of gnomesu? dani@marvin:~> ps aux | grep gnomesu dani 7650 0.0 0.0 1596 476 pts/1 S+ 15:58 0:00 grep gnomesu dani@marvin:~> gnomesu & [1] 7653 dani@marvin:~> # pressing cancel dani@marvin:~> ps aux | grep gnomesu dani 7653 3.5 1.8 35708 9304 pts/1 S 15:58 0:00 gnomesu root 7656 0.0 0.2 3248 1152 pts/1 S 15:58 0:00 /opt/gnome/lib/libgnomesu/gnomesu-pam-backend 17 16 root gnome-terminal dani 7665 0.0 0.0 1600 472 pts/1 R+ 15:58 0:00 grep gnomesu dani@marvin:~> # gnomesu is waiting until gnomesu-pam-backend ends dani@marvin:~> ps aux | grep gnomesu dani 7653 0.9 1.8 35708 9304 pts/1 S 15:58 0:00 gnomesu root 7656 0.0 0.2 3248 1152 pts/1 S 15:58 0:00 /opt/gnome/lib/libgnomesu/gnomesu-pam-backend 17 16 root gnome-terminal dani 7673 0.0 0.0 1596 472 pts/1 R+ 15:59 0:00 grep gnomesu dani@marvin:~> kill -9 7656 dani@marvin:~> ps aux | grep gnomesu dani 7680 0.0 0.0 1596 476 pts/1 S+ 15:59 0:00 grep gnomesu [1]+ Exit 255 gnomesu dani@marvin:~> A backtrace and strace would be helpful. gnomesu after STRG+C to get backtrace: Program received signal SIGINT, Interrupt. [Switching to Thread 1090222304 (LWP 7079)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40f04860 in __nanosleep_nocancel () from /lib/tls/libc.so.6 #2 0x40f2f82a in usleep () from /lib/tls/libc.so.6 #3 0x406a7725 in __gnomesu_consolehelper_service_new () from /opt/gnome/lib/libgnomesu.so.0 #4 0x406a4690 in gnomesu_spawn_async2 () from /opt/gnome/lib/libgnomesu.so.0 #5 0x406a4718 in gnomesu_spawn_async () from /opt/gnome/lib/libgnomesu.so.0 #6 0x406a480b in gnomesu_spawn_command_async () from /opt/gnome/lib/libgnomesu.so.0 #7 0x080490a4 in main () (gdb) backtrace of gnomesu-pam-backend: (gdb) bt #0 0xffffe410 in ?? () #1 0xbf820fb4 in ?? () #2 0x00001000 in ?? () #3 0x40017000 in ?? () #4 0x401ae4c3 in __read_nocancel () from /lib/tls/libc.so.6 #5 0x4015f078 in _IO_file_read_internal () from /lib/tls/libc.so.6 #6 0x4015ddfe in _IO_new_file_underflow () from /lib/tls/libc.so.6 #7 0x401602eb in _IO_default_uflow_internal () from /lib/tls/libc.so.6 #8 0x401600cc in __uflow () from /lib/tls/libc.so.6 #9 0x40155228 in _IO_getline_info_internal () from /lib/tls/libc.so.6 #10 0x4015514f in _IO_getline_internal () from /lib/tls/libc.so.6 #11 0x4015406c in fgets () from /lib/tls/libc.so.6 #12 0x08049216 in su_conv (num_msg=1, msg=0xbf8214dc, resp=0xbf8214d8, data=0x0) at pam.c:82 #13 0x4025f42e in pam_sm_chauthtok () from /lib/security/pam_unix2.so #14 0x402603e8 in pam_sm_authenticate () from /lib/security/pam_unix2.so #15 0x400c5f1a in _pam_dispatch () from /lib/libpam.so.0 #16 0x400c809e in pam_authenticate () from /lib/libpam.so.0 #17 0x08049591 in main (argc=5, argv=0xbf8419c4) at pam.c:235 #18 0x40113ea0 in __libc_start_main () from /lib/tls/libc.so.6 #19 0x08049071 in _start () at start.S:119 dani@marvin:~> sudo strace -p `pidof gnomesu-pam-backend` Process 7155 attached - interrupt to quit read(17, and nothing happens... this keeps gnomesu open (in terminal - gui disappears). process while getting this data: dani@marvin:~> ps aux | grep gnomesu dani 7154 0.1 1.8 35708 9304 pts/5 S+ 19:15 0:00 gnomesu root 7155 0.0 0.2 3252 1156 pts/5 S+ 19:15 0:00 /opt/gnome/lib/libgnomesu/gnomesu-pam-backend 17 16 root gnome-terminal dani 7361 0.0 0.0 1596 472 pts/8 S+ 19:23 0:00 grep gnomesu further inforamtion? Well, it looks like gnome-su is launching the pam backend and that never returns, its wedged in pam doing what looks like a blocking read. Is this 32bit? NEEDINFO'ing pam maintainer. yes, it is 32bit.
the gnomesu-pam-backend reads this way
pam-backend/pam.c:82:
if (!fgets (password, sizeof (password), inf)) {
fgets will not reach EOF while reading, when gnomesu close the file descriptor.
gnomesu have to send something, before closing the file descriptor, which will bring fgets to return 0.
If gnomesu closes the file descriptor it will cause an EOF. Before you cancel, can you run ps ax | grep gnomesu for the command line args. Before cancel: dani@linux:~> gnomesu & [1] 13849 dani@linux:~> ps ax | grep gnomesu 13849 pts/12 S 0:00 gnomesu 13852 pts/12 S 0:00 /opt/gnome/lib/libgnomesu/gnomesu-pam-backend 16 15 root gnome-terminal 13860 pts/12 S+ 0:00 grep gnomesu After cancel: dani@linux:~> ps ax | grep gnomesu 13849 pts/12 S 0:00 gnomesu 13852 pts/12 S 0:00 /opt/gnome/lib/libgnomesu/gnomesu-pam-backend 16 15 root gnome-terminal 13896 pts/12 S+ 0:00 grep gnomesu So if after cancel gnomesu is still around, it explains why the pam backend does not exit (although I have still not managed to replicate this). The arguments on my beta 4.2 machine are basically the same.
Just above the loop:
while (waitpid (mypid, &status, WNOHANG) == 0) {
The file descriptor is explicitly closed:
fclose (f);
close (child_pipe[1]);
Are you certain this is beta 5? Beta 4.2 of NLD 10 has a common code base and that has libgnomesu-1.0.0-14
Can you install lastest from STABLE with the debuginfo packages and get a better trace of gnomesu in the hang?
Also, strace -f gnomesu, cancel and attach the output. Should be able to see the file descriptors getting closed.
Ok finally. You have to replicate this with esd enabled in gnome configuration but not running. esd gets exec'd after the g76:/suse/jpr # lsof | grep 70520 gnomesu-p 29003 root 15r FIFO 0,5 70520 pipe esd 29005 tux 16w FIFO 0,5 70520 pipe g76:/suse/jpr # lsof | grep 70519 gnomesu-p 29003 root 14w FIFO 0,5 70519 pipe esd 29005 tux 13r FIFO 0,5 70519 pipe esd forks and execs via libgnome Dan has a way to fix this via CLOEXEC. Marcus, its not clear to me how much of security issue this is. patched esound submitted to autobuild |
When you run gnomesu and press the cancel button instead of entering a password, then gnomesu will hang. It's seems that the gnomesu-pam-backend is still running in the background and listing on the file descriptor of the parent (gnomesu), this will lead to that the gnomesu don't leave the waitpid loop because the pam backend will not quit. version of libgnomesu: 1.0.0-11 gnomesu will hang in the loop in src/services/pam.c:257 while (waitpid (mypid, &status, WNOHANG) == 0) { gnomesu-pam-backend will hang in pam-backend/pam.c:82 if (!fgets (password, sizeof (password), inf)) { fgets will never return 0. I hope this will help and not confuse.