appmenu doesn't work with apps run as sudo root

Still happening with 0.0.6.

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.

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

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

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.

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.

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.

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.

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

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
>

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

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
>

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

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

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
>

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.

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.

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.

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.

>>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.

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

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.

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.

>>Dave

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

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?
>

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

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
>

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? :-)

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

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.