Bug 159958 - User cannot run ethereal in unprivildged mode
User cannot run ethereal in unprivildged mode
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: usermode (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Miloslav Trmač
David Lawrence
: 166642 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-06-09 14:44 EDT by Michael K. Ellis
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:00:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael K. Ellis 2005-06-09 14:44:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Description of problem:
Attempting to open ethereal as an unprivilged user:

$ ethereal

Warning window opens asking for root password.  When clicking on the 'unprivilged' button, program exits with 'Unknown Error' window and a close button.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open Ethereal as non-root user.
2. Select 'Unpriviliged' button
3. Program exits with 'Unknown Error'.

Actual Results:  Program exits with a '0' result code.

Expected Results:  Program opens with non-privilged user permissions, allowing a user to do an ethereal analysis of a packet capture owned by the user.

Additional info:
Comment 1 Radek Vokal 2005-06-22 08:19:10 EDT
Seems more like a consolehelper bug, reassing to component owner for some inputs.
Comment 2 Pierre Ossman 2005-08-19 02:59:34 EDT

Program received signal SIGSEGV, Segmentation fault.
0x0804adf2 in converse_pipe (num_msg=0, msg=0x0, resp=0x0,
    appdata_ptr=0xbfc03224) at userhelper.c:408
408             if ((get_pam_string_item(data->pamh, PAM_USER, &user) !=
(gdb) bt
#0  0x0804adf2 in converse_pipe (num_msg=0, msg=0x0, resp=0x0,
    appdata_ptr=0xbfc03224) at userhelper.c:408
#1  0x0804b570 in pipe_conv_exec_start (conv=Variable "conv" is not available.
) at userhelper.c:943
#2  0x0804c494 in wrap (user=0x8c51b68 "ossman",
    program=0xbfc039d0 "ethereal", conv=0xbfc032a4, text_conv=0xbfc0329c,
    prompt=0x804ab3d <prompt_pipe>, argc=3, argv=0xbfc03354)
    at userhelper.c:1999
#3  0x0804d50f in main (argc=3, argv=0xbfc03354) at userhelper.c:2502

(gdb) print *((struct app_data*)appdata_ptr)
$4 = {pamh = 0x8c52c08, fallback_allowed = 1, fallback_chosen = 1,
  canceled = 0, input = 0x8c50358, output = 0x8c504c0, banner = 0x0,
  domain = 0xbfc039d0 "ethereal", sn_name = 0x0, sn_description = 0x0,
  sn_wmclass = 0x0, sn_binary_name = 0x0, sn_icon_name = 0x0, sn_id = 0x0,
  sn_workspace = -1}
Comment 3 Pierre Ossman 2005-08-19 03:14:20 EDT
It would seem that a bogus pointer is being written into &user:

(gdb) print user
$16 = 0x2000000 <Address 0x2000000 out of bounds>

The place of the sigsegv is also an optimised strlen(user) == NULL:

Dump of assembler code for function converse_pipe:
0x0804adcc <converse_pipe+0>:   push   %ebp
0x0804adcd <converse_pipe+1>:   mov    %esp,%ebp
0x0804adcf <converse_pipe+3>:   push   %edi
0x0804add0 <converse_pipe+4>:   push   %esi
0x0804add1 <converse_pipe+5>:   push   %ebx
0x0804add2 <converse_pipe+6>:   sub    $0x3c,%esp
0x0804add5 <converse_pipe+9>:   lea    0xfffffff0(%ebp),%ecx
0x0804add8 <converse_pipe+12>:  mov    $0x2,%edx
0x0804addd <converse_pipe+17>:  mov    0x14(%ebp),%ebx
0x0804ade0 <converse_pipe+20>:  mov    (%ebx),%eax
0x0804ade2 <converse_pipe+22>:  call   0x804a5a4 <get_pam_string_item>
0x0804ade7 <converse_pipe+27>:  test   %eax,%eax
0x0804ade9 <converse_pipe+29>:  jne    0x804adf7 <converse_pipe+43>
0x0804adeb <converse_pipe+31>:  mov    0xfffffff0(%ebp),%eax
0x0804adee <converse_pipe+34>:  test   %eax,%eax
0x0804adf0 <converse_pipe+36>:  je     0x804adf7 <converse_pipe+43>

0x0804adf2 <converse_pipe+38>:  cmpb   $0x0,(%eax)

0x0804adf5 <converse_pipe+41>:  jne    0x804adff <converse_pipe+51>
0x0804adf7 <converse_pipe+43>:  mov    $0x804f099,%eax
0x0804adfc <converse_pipe+48>:  mov    %eax,0xfffffff0(%ebp)
0x0804adff <converse_pipe+51>:  mov    %eax,0x10(%esp)
0x0804ae03 <converse_pipe+55>:  movl   $0x2a,0xc(%esp)

So this seems to be PAM bug.
Comment 4 Jindrich Novy 2005-08-19 03:23:52 EDT
Ok, reassigning to Tomas. Thanks for the analysis.
Comment 5 Tomas Mraz 2005-08-19 04:17:01 EDT
I'm not sure this is a PAM bug and I'm confused with the backtrace - this isn't
backtrace from a RHEL-3 userhelper but rather a FC-4 one.

This can be a completely different bug than the original report I think.

Pierre, which exact usermode version do you use? And on which exact
circumstances the crash happens?
Comment 6 Pierre Ossman 2005-08-19 04:23:01 EDT
Sorry, didn't see this was RHEL.

I'm running usermode-1.80-1. The bug appears when I click 'Run Unprivileged'.
Which application that is involved is irrelevant.
Comment 7 Tomas Mraz 2005-08-19 05:54:52 EDT
Hmmm back to userhelper - it calls pam functions after it had released the pam
handle by pam_end() call. Really nice work! :(

I've commented out the converse_pipe(0, NULL, NULL, data); at line 945 of
userhelper.c and it seems to work fine now. But I'm not sure this is the right
fix or if it isn't better to call the pam_end() in the fall back case after the

I didn't look at the RHEL-3 version but most probably there will be the same
Comment 8 Radek Vokal 2005-08-24 03:01:54 EDT
*** Bug 166642 has been marked as a duplicate of this bug. ***
Comment 9 Pierre Ossman 2005-10-14 10:07:34 EDT
This is fixed in the current version of usermode (1.18-1 on FC devel). Go ahead
and close if the problem is gone on RHEL aswell.
Comment 10 RHEL Product and Program Management 2007-10-19 15:00:57 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.