appmenu doesn't work with apps run as sudo root

Bug #592842 reported by Jeremy Bícha
696
This bug affects 131 people
Affects Status Importance Assigned to Milestone
Application Menu Indicator
Triaged
Low
Unassigned
indicator-appmenu (Ubuntu)
Triaged
Low
Unassigned

Bug Description

appmenu doesn't work with apps run as sudo root.
I tested with synaptic, gksu gedit, and sudo gedit.

possible duplicate of bug 587353

Jeremy Bícha (jbicha)
tags: removed: crash
Jeremy Bícha (jbicha)
description: updated
Revision history for this message
Hernando Torque (htorque) wrote :

Still happening with 0.0.6.

Changed in indicator-appmenu:
status: New → Confirmed
Revision history for this message
David Barth (dbarth) wrote :

This is not supported at the moment. There are 2 aspects to this bug.

The first aspect is that we use standard dbus calls, and don't differentiate between the real and effective user id to connect to the session bus. As a result, sudo apps are sharing a /distinct/ bus. dbusmenu could workaround that potentially.

The second aspect (more serious) is that the security implications would probably dictate that menus of sudo apps be exposed with some special color or rendering, to ensure the user is conscious that he is interacting with privileged apps. That's more a design aspect.

On the latter, you can argue however that sudo apps are currently displayed as normal apps, so the solution for that design is actually a more general problem to address.

Changed in indicator-appmenu:
importance: Undecided → Wishlist
milestone: none → maverick-alpha-3
David Barth (dbarth)
Changed in indicator-appmenu:
milestone: maverick-alpha-3 → none
Revision history for this message
Omer Akram (om26er) wrote :

gparted runs as sudo(or something like that) and is on the live cd.

Changed in indicator-appmenu (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Mio (m10) wrote :

I think it is quite a big inconsistency for unity.. most users won't understand why some ("native") applications that ship directly with ubuntu have the menus the traditional way..
the visual differentiation between root and non-root application is not an issue here since it has nothing to do with the menus specifically imho

Revision history for this message
quequotion (quequotion) wrote :

This is confusing, distracting and reducing productivity.

Here's a proposal:

indicator-appmenu gets, initially, read-only access to the root dbus (in order to draw the menu) and then asks for a password on the first menu call (by either mouse click or keyboard shortcut). All root privileges drop once the window is out of focus or closed.

This only requires that indicator-applet temporarily take elevated privileges. It would be important to drop privileges both for closing windows and windows loosing focus since a user application could take advantage of the raised privileges unless they were somehow isolated.

Having to enter a password is probably indication enough that an application has raised privileges.

If it were not, the root menu could be drawn with inversion of highlight (selected/mouseover) and unhighlighted (unselected/normal) colors.

Revision history for this message
Tynach (tynach2) wrote :

Hmm, why not start up another process for indicator-appmenu? Depending on if it's a root application, or a user application, decides which one is displayed up there at the moment. This allows security, hopefully.

The idea is, the user's indicator-appmenu is the only one running while under normal opperations. But as soon as gksu is called, it will not only start up the called application, but also a root process for indicator-appmenu. It should also check to see if indicator-appmenu is already running as root, so it doesn't duplicate it multiple times, instead using the same one if multiple programs are being run as root (like gedit and synaptic).

When elevated privileges are dropped (when no root applications are running), it should probably quit. Or maybe not, to improve startup times on further instances of root programs. Up to you.

And of course, if a non-root-user window is highlighted, the bar shows the indicator-appmenu running as the current user.

This also potentially fixes the problem if people run programs as other users, not just as root, as it can start an indicator-appmenu for each user programs are being run as.

Revision history for this message
D (tenswiths) wrote :

I was going to file a bug about appmenu not working with programs launched as another user (not necessarily root) with gksu. Would I be right in thinking that solving this current bug would solve that?

As I'm about to prove, I'm no programmer or software designer, but here's a possible solution to David Barth's second concern: In cssm, there is a module (Title Bar Info) that puts the word "ROOT:" in the window title of root apps. At present, appmenu (or the panel?) does not reflect this i.e. it doesn't show "ROOT:". If you could find a way to "grab" this info from the window title (and switch on the module, which isn't on by default, and may not even be installed until cssm is) this might be a workable solution.

Revision history for this message
Dàrent (animaletdesequia) wrote :

Hi David H, i don't think that's possible. I use that plugin in compiz than you refer, but that plugin only affects to the title bar info, and the problem is with the menu bar. The title bar and the menu bar are diferent modules as I understand it (not a programer neither) and so are controlled by diferent processes. For instance, your title bar can be controled by gtk-window-decorator or by emerald, while the menubar is controled by the gtk directly, if I'm not wrong...

Anyway, i read some people says the lack of global menu in root windows is not a bug, its made on purpose, because they considered than having a menu with root privileges outside the window than owns it was dangerous. You may be doing some mistake in a root menu thinking you are manipulating another user window's menu. But I used the globalmenu plugin in maverick, which worked in all windows and never had a problem.

Let's see if somebody makes a workarround to make it works system-wide.

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

Issue is still present in Oneiric, I can reproduce it with "sudo gedit" and "sudo gnome-terminal".

Revision history for this message
Joaquin (jknvv13) wrote : Re: [Bug 592842] Re: appmenu doesn't work with apps run as sudo root

I installed synaptic and it's happening the same.
El 02/10/2011 12:40, "Dmitry Shachnev" <email address hidden> escribió:

> Issue is still present in Oneiric, I can reproduce it with "sudo gedit"
> and "sudo gnome-terminal".
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (747203).
> https://bugs.launchpad.net/bugs/592842
>
> Title:
> appmenu doesn't work with apps run as sudo root
>
> Status in The Application Menu:
> Confirmed
> Status in “indicator-appmenu” package in Ubuntu:
> Triaged
>
> Bug description:
> appmenu doesn't work with apps run as sudo root.
> I tested with synaptic, gksu gedit, and sudo gedit.
>
> possible duplicate of bug 587353
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-appmenu/+bug/592842/+subscriptions
>

Revision history for this message
David Gomes (davidgomes) wrote :

Well, from what I heard, it's not easy to fix, and might even not be fixed.

Revision history for this message
Joaquin (jknvv13) wrote :

Ummm... I think it's possible, a "proxy" that sends menu from root session
to your panel.
El 02/10/2011 13:25, "David Gomes" <email address hidden> escribió:

> Well, from what I heard, it's not easy to fix, and might even not be
> fixed.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (747203).
> https://bugs.launchpad.net/bugs/592842
>
> Title:
> appmenu doesn't work with apps run as sudo root
>
> Status in The Application Menu:
> Confirmed
> Status in “indicator-appmenu” package in Ubuntu:
> Triaged
>
> Bug description:
> appmenu doesn't work with apps run as sudo root.
> I tested with synaptic, gksu gedit, and sudo gedit.
>
> possible duplicate of bug 587353
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-appmenu/+bug/592842/+subscriptions
>

Revision history for this message
Satchit Bhogle (satchitb) wrote :

A yellow-and-black "hazard" striped toolbar would easily communicate that root is dangerous, and would clearly differentiate it from the regular applications.

Revision history for this message
Joschi Poschi (joschiposchi) wrote :

I also think that applications currently using root privileges
          1. should have an optical identification
BUT 2. really should use the global menu/appmenu for consistency reasons.

Using the normal menu lets every application look crappy and I think regarding 'design' it's a weak point to use the normal menu instead of the global menu/appmenu for distinguishing normal/root privilege applications

Revision history for this message
Andrey Gelman (andrey-gelman) wrote :

Normal menu as opposed to global menu cannot be considered as something
that distinguishes between normal/root privilege applications, as there
are applications like LibreOffice and others that just do not implement
global menu integration, so this would be misleading.

On 12/01/2011 05:48 PM, Johannes Gowin wrote:
> I also think that applications currently using root privileges
> 1. should have an optical identification
> BUT 2. really should use the global menu/appmenu for consistency reasons.
>
> Using the normal menu lets every application look crappy and I think
> regarding 'design' it's a weak point to use the normal menu instead of
> the global menu/appmenu for distinguishing normal/root privilege
> applications
>

Revision history for this message
David Gomes (davidgomes) wrote :

And Emacs too. In other operating systems that use Global Menus (like Mac OS), global menus are consistent, and even work with Java menus. I think the Ubuntu AppMenu should work like that, consistent for all applications.

Revision history for this message
Greg Merchan (gregory-merchan) wrote :

I thought synaptic was just a poorly written app because it somehow prevented the menu from going global, until I ran it without privileges from the command line a moment ago.

Revision history for this message
quequotion (quequotion) wrote :

gnome-globalmenu could display menus from both user and suid applications.

unfortunately it only worked with gtk applications, but maybe there's something in the code that could be applied to indicator-appmenu.

Revision history for this message
Ted Gould (ted) wrote :

On Tue, 2012-02-14 at 18:25 +0000, quequotion wrote:
> gnome-globalmenu could display menus from both user and suid
> applications.
>
> unfortunately it only worked with gtk applications, but maybe there's
> something in the code that could be applied to indicator-appmenu.

No, the way it worked was significantly different. It's one of the
downsides of using DBus over the X protocol like it was doing.

Revision history for this message
quequotion (quequotion) wrote :

>>Ted

Canonical's appmenu is also using DBus.

I don't know the details of how it worked exactly, but I remember non-gtk2 applications (like firefox) never worked with gnome-globalmenu and I also remember getting global menus for applications run with gksu.

Revision history for this message
Aleve Sicofante (sicofante) wrote :

Very inconsistent behavior. How can this be considered "Wishlist"?

Revision history for this message
Dave Ahlswede (mightyquinn) wrote :

This is still a problem? The Gnome-globalmenu people had the same problem briefly after switching to dbus, but they had it fixed within a couple months.

Revision history for this message
Andrey Gelman (andrey-gelman) wrote :

On 06/14/2012 07:08 AM, Dave Ahlswede wrote:
> This is still a problem? The Gnome-globalmenu people had the same
> problem briefly after switching to dbus, but they had it fixed within a
> couple months.
>
Yes.
Run, say, 'sudo gedit' from commandline, and see for yourself.

Revision history for this message
quequotion (quequotion) wrote :

>>Dave

I remember this too. Do you now how it was done?

Revision history for this message
Andrey Gelman (andrey-gelman) wrote :

sudo gedit
gedit will start with no global menu integration.

On 08/05/2012 02:50 AM, quequotion wrote:
>>> Dave
> I remember this too. Do you now how it was done?
>

Omer Akram (om26er)
Changed in indicator-appmenu:
importance: Wishlist → Low
status: Confirmed → Triaged
Revision history for this message
Gruntzen (gruntzen-deactivatedaccount) wrote :

Does anybody know if this bug is anywhere near being fixed? It's a huge annoyance when using root-privileged applications.

Revision history for this message
Hanine HAMZIOUI (hanynowsky) wrote :

I have heard that it would be "Won't Fix" unfortunately. For security
reasons when running apps with root privilege, access to menu proxy is
denied.

On Tue, Feb 5, 2013 at 4:03 PM, Gruntzen <email address hidden> wrote:

> Does anybody know if this bug is anywhere near being fixed? It's a huge
> annoyance when using root-privileged applications.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (981495).
> https://bugs.launchpad.net/bugs/592842
>
> Title:
> appmenu doesn't work with apps run as sudo root
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-appmenu/+bug/592842/+subscriptions
>

Revision history for this message
David Prosén (david13) wrote :

It would be a big advantage if it could be fixed so it is possible to run Linux like OS X but without this menu issue.
I don't know any other stuff on my computer that I am not satisfied with?
Maby we could start fund raising for this? :-)

Revision history for this message
Oxwivi (oxwivi) wrote :

Is there any workarounds like telling the sudoed apps to use the user's bus session?

Revision history for this message
Oxwivi (oxwivi) wrote :

I found you could set DBUS_SESSION_BUS_ADDRESS variable, but it gives an error:

$ sudo DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS gnome-terminal
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: The connection is closed

For the record, I want to integrate apps running in remote machines and LXC containers into Unity. Obviously they share the same issue are trying to integrate sudoed apps, namely the apps using session bus specific to the remote machine or container. As such, I'm trying to mount my local bus session to the container and telling the apps to use it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.