While using more traditional way to run wireshark in "enabled" mode like, e.g., running su command prior to wireshark itself, using gksu-polkit didn't work for me. 1/ when being in home directory of the current user: Following dialog is displayed: > Can't get pathname of Wireshark: PATH isn't set. > It won't be possible to capture traffic. > Report this to the Wireshark developers. No device can be selected for capture and strangely, after a minute or so, Wireshark completely disappears, while gksu-polkit still runs back in terminal. Doing Ctrl-C here leads to (single) line like this being printed: > ** (gksu-polkit:22971): WARNING **: > Method invoked for SendSignal returned FALSE but did not set error Only way to claim terminal back (without switching to another) is to suspend the process (^Z) and then kill it using SIGKILL. 2/ when being in the root (/): Following traceback is generated: > Traceback (most recent call last): > File "/lib64/python2.7/site.py", line 567, in <module> > main() > File "/lib64/python2.7/site.py", line 549, in main > known_paths = addusersitepackages(known_paths) > File "/lib64/python2.7/site.py", line 278, in addusersitepackages > user_site = getusersitepackages() > File "/lib64/python2.7/site.py", line 253, in getusersitepackages > user_base = getuserbase() # this will also set USER_BASE > File "/lib64/python2.7/site.py", line 243, in getuserbase > USER_BASE = get_config_var('userbase') > File "/lib64/python2.7/sysconfig.py", line 521, in get_config_var > return get_config_vars().get(name) > File "/lib64/python2.7/sysconfig.py", line 420, in get_config_vars > _init_posix(_CONFIG_VARS) > File "/lib64/python2.7/sysconfig.py", line 299, in _init_posix > raise IOError(msg) > IOError: invalid Python installation: unable to > open //include/python2.7/pyconfig-64.h (No such file or directory) I believe both 1/ and 2/ use cases should work without fiddling with PATH exports or anything like this, and definitely no traceback is expected. $ rpm -qf $(which gksu-polkit) $(which wireshark) gksu-polkit-0.0.3-6.fc18.x86_64 wireshark-gnome-1.8.6-4.fc18.x86_64
re [comment 0]: > While using more traditional way to run wireshark in "enabled" mode like, > e.g., running su command prior to wireshark itself (accidentally omitted) ... works well [*] ... [*] when warnings like this put aside: > (wireshark:25175): IBUS-WARNING **: > The owner of /home/jpokorny/.config/ibus/bus is not root!
The same is observed in Fedora 19 (beta TC2): $ rpm -qf $(which gksu-polkit) $(which wireshark) gksu-polkit-0.0.3-5.fc19.x86_64 wireshark-gnome-1.8.6-4.fc19.x86_64
When testing the reproducer (100% for me), you may need to follow a workaround as per [bug 948613].
re [comment 0]: Running wireshark as a normal user like this: gksu-polkit env PWD=/root /usr/sbin/wireshark also helped ... for like one minute after which it disappeared "as usual". So there must be some utterly broken condition related to $PWD envvar...
FWIW, gksu-polkit killing its slave after minute or so is now reported as a separate [bug 975541].
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Being on F19 now: wireshark-1.10.5-1.fc19.x86_64 gksu-polkit-0.0.3-8.gitf8ce834c.fc19.x86_64 and here's a current review of the previously mentioned points: [comment 1]: gksu-polkit wireshark re 1/: "PATH dialog" is displayed, no interface can be selected; wireshark disappearing explained in [comment 5] re 2/: no such traceback appears, behaves exactly as in 1/, (i.e., "PATH dialog" is displayed, no interface can be selected) And now, here's a recap of what currently work: su; wireshark su -; wireshark su -c wireshark gksu-polkit env PATH=$PATH wireshark [*] gksu-polkit /usr/sbin/wireshark (in fact almost same as in [comment 4]) So it looks like some related issues went away since F18, and the only debatable issue is whether it's sane that wireshark requires PATH env. variable set when it is executed as "gksu-polkit wireshark". Keeping this around for 19, but not going to bump this anymore if there is no interest. [*] default env as prepared as part of gksu-polkit initiated execution: $ gksu-polkit env > XAUTHORITY=/tmp/gksu-polkit-XVTpG1/.Xauthority > DESKTOP_STARTUP_ID=gksu-polkit/env/28131-0-juicyfruit_TIME0 > DISPLAY=:0
If there were some other mechanism by which Wireshark could find the containing directory of its executable, or if, on some platforms, it had the pathname of dumpcap (the program that does traffic capture; this is done as a separate program so that only that relatively-small program needs additional privileges in order to open devices on which to capture), it wouldn't use $PATH to try to find its containing directory and look for dumpcap in the same directory. Then again, as per this is done as a separate program so that only that relatively-small program needs additional privileges in order to open devices on which to capture above, and as per http://anonsvn.wireshark.org/viewvc/trunk/doc/README.packaging?view=co which says In versions up to and including 0.99.6, it was necessary to run Wireshark with elevated privileges in order to be able to capture traffic. With version 0.99.7, all function calls that require elevated privileges have been moved out of the GUI to dumpcap. WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT. you *really* don't want to be running Wireshark with any additional privileges - you want to do whatever is necessary to arrange that *dumpcap* run with whatever privileges are needed to capture.
Thanks, Guy, got the point. In fact that inelegant and risky workaround (it's just that I admit) would not be brought at all if I noticed the hints "Are you a member of the 'wireshark' group?" (very light gray on white background in my desktop theming) ... or more proactive. Proper solution to run a fully-fledged wireshark is as simple as: $ su -c 'usermod -a -G wireshark myusername' $ sg wireshark wireshark - no more risk than needed - no swimming against stream as in my previous gksu-polkit case I see $PATH requirement of wireshark is legitimate one. Still it's questionable if gksu-polkit should drop PATH rather than, e.g., trying to set sane defaults, or simply make things work just if they were executed with plain 'su -c'. It may have something to do with whether shell is used in the background (it could be easily mimicked if only gksu-polkit didn't try to interpret any switch as its own: [bug 975531]).
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.