(as superuser) in title bar

[SYN-cook]

Question asked by sullybear on Wordpress: I notice that the title bar in firefox shows “(as superuser)” is that normal? Or did I goof a setting?

Reply from netblue30: The sandbox process itself runs as root. The application inside the sandbox runs as a regular user. I don’t know why firefox shows as superuser, “ps aux | grep firefox” reports it as a regular user. I would say is a bug in firefox.

I want to add that I observe the same behavior for other applications as well, i.e. VLC, Audacious, Transmission. In all these cases, the title bar claims that the application is running as root. At the same time, the sandbox appears to work perfectly.

Firejail version 0.9.36

[ssokolow]

I don't have time to test it myself right now, but have you tried running python -c 'import os; print(os.getresuid())' under firejail?

That'll return the real, effective, and saved UIDs. All of the listed apps are GTK+ apps, so I suspect either GTK+ or maybe your window manager has some code which is reading one of those values and firejail forgot to reset it.

If you want to narrow down the culprit, I'd...

1. Try some Qt apps (If you need suggestions, Filelight, Okular, AntiMicro, K3b, and Krita are all superior to their closest GTK+ analogues by either having a more comprehensive feature-set or being more efficient for the same feature set.)
2. Try some apps using 'none of the above' toolkits like gitk or PySolFC (Tk) and xterm/urxvt/etc. (No need to test using VCL (LibreOffice), wxWidgets (Audacity, aMule, etc.), and SWT (eg. various Java apps) since they are wrappers and use another toolkit under the hood. Typically GTK+, but VCL can also use Qt.)
3. Use xprop | egrep '^_NET_WM_PID' to see if the presence or absence of "(as superuser)" has any correlation to the presence or absence of the _NET_WM_PID window property that's used to look up processes from windows. (Because X began as a network-transparent system, the ability to look up a process ID from a window ID was bolted on afterward and is optional. If only things with _NET_WM_PID display "(as superuser)", then it may be a sign that the WM is adding it.)

[SYN-cook]

Thanks for your suggestions, I played around a little yesterday and here is what I found:

1. Apparently, whether a window belongs to superuser is determined only at window creation. When I switch the user to root in a terminal, the title bar doesn't update. Consistent with this, running firejail in a terminal doesn't change its titlebar. When root, however, from a terminal opens a new terminal, the title bar may (e.g. xterm) or may not (e.g. urxvt) contain (as superuser).
2. No surprises with python -c 'import os; print(os.getresuid())': It always returns the current user, also from within firejail. Let me demonstrate:
   1. root opens a new xterm window, (as superuser) is written in the titlebar. python -c 'import os; print(os.getresuid())' returns (0, 0, 0)
   2. su to user without root privileges, (as superuser) is still written in the titlebar. python -c 'import os; print(os.getresuid())' returns (1000, 1000, 1000)
   3. Run firejail, (as superuser) is still written in the titlebar. python -c 'import os; print(os.getresuid())' returns (1000, 1000, 1000)
3. Qt apps (e.g. Qtiplot) behave like GTK+ apps and display (as superuser) in their titlebar. urxvt aside, I found that applications with Tk framework (e.g. BKchem, PySolFC) don't show (as superuser) in their titlebar when running in firejail.
4. No matter if firejail is involved or not (see my first point), the appearance of (as superuser) in the window title strictly correlates with the _NET_WM_PID window property.

I run Debian Jessie Mate, thus my window manager is Metacity (Marco) 1.8.2.

[ssokolow]

If there's a strict correlation between the presence of _NET_WM_PID and the presence of "(as superuser)", I'd say that makes it pretty likely that it's Metacity adding it.

As for switching the user to root after opening the terminal, the terminal itself still wouldn't be running as root... it'd just be the process running within the terminal which got elevated. A more meaningful question would be whether it'd lose the "(as superuser)" if setuid() and some other calls were used to drop privileges within the process referenced by _NET_WM_PID.

The next thing I'd suggest is installing a window manager with minimal dependencies like Openbox and then temporarily swapping it in with openbox --replace (and then metacity --replace to return to normal) to confirm the hypothesis that it's Metacity doing it.

If Metacity is responsible, the simplest way to identify the solution would be to grab a source tarball for it and grep for "as superuser" to figure out what it's conditional on.

Failing that, you could try narrowing down the cause with a few other experiments:

1. Check if the Python os.getlogin() call returns a different user than os.getresuid()
2. Try running xterm -hold -e export under "(as superuser)" conditions to see if any environment variables might be responsible (The cause doesn't even have to be within the same process or a child. You can inspect the environment of any other process running at the same user via the /proc/<PID>/environ virtual file)
3. Try running setsid between the su and terminal call to see if running the program in a new session helps.
4. I don't have some code handy, but you could try running the terminal from a Python script after calling os.setpgrp() to ensure it's running in a fresh process group.
5. Use bash --login in between your su call and launching a new terminal. (Just a thought. It might be walking up the process ancestry hierarchy to find the root for the login session and firejail isn't doing something that a normal login does to reset things. If so, bash --login might cause different results.)

[netblue30]

I've seen this problem at some point on Debian Wheezy, then something got updated and it totally disappeared. I think it has something to do with the window/desktop manager.

[SYN-cook]

From Mate running, I executed openbox --replace and it resolved the issue completely! However, when I returned to Marco afterwards, the (as superuser) title bars did not reappear. For them to reappear, I needed to logout and login again.

Further, running marco --replace in the first place also resolves the issue.

I searched the Metacity sources and found the (as superuser) string in core/window-props.c /~https://github.com/GNOME/metacity/blob/master/src/core/window-props.c

[ssokolow]

OK, reading upward reveals that it's triggered by window_owner being equal to 0 and that window_owner is set by a call to owner_of_process which, sure enough, takes window->net_wm_pid as input.

Searching reveals owner_of_process to be defined in the same file at line 492 and that, in the successful case, it delegates the task of actually finding the process's owner to glibtop_get_proc_uid.

A quick Google search reveals that to be part of libgtop and a quick GitHub "This repository" search narrows it down to the file libgtop/sysdeps/common/default.c, where it's a simpler-to-use wrapper for the function glibtop_get_proc_uid_l.

However, I'm having trouble finding the actual definition of that last function.

[SYN-cook]

Sorry, I don't know if this helps: http://sourcecodebrowser.com/libgtop/2.22.0/procuid_8h.html#aff3a9a5a3afb876e35bad14e850a56e6

[ssokolow]

That definitely helps. It looks like glibtop_get_proc_uid_l has two different behaviours depending on whether it's going to call a gtop server or perform the query within the same process. The server approach appears to just be sending a request over a socket and receiving a response, so I decided to see if the non-server path did anything relevant since that's easier to trace with that site...

1. It calls glibtop_get_proc_uid_s
2. glibtop_get_proc_uid_s calls _glibtop_get_procinfo to retrieve the struct containing the uid member we care about.
3. _glibtop_get_procinfo repeatedly calls a function named getprocs to populate server and then, upon finding a match, returns &server->machine.last_pinfo.

Unfortunately, getprocs doesn't get auto-hyperlinked by that tool and I'm too sleepy to investigate further there or to start looking for the server code, so digging deeper will have to wait for another day.

[ghost]

For me, MATE shows as if programs are running as root. XFCE and KDE, however, don't.

[0xBRM]

@Amarildojr KDE 4.14 here and it shows firefox running (as superuser).

[ghost]

@CrisBRM Yes. I remember running firejail in Debian Jessie and experiencing the same thing. However, I use Arch and thus KDE is on version 5.

[SYN-cook]

OK, I don't see this any more in current Debian Testing Mate (with Mate 1.14), while the issue is still there in a freshly installed Debian Jessie Mate (with Mate 1.8).

Further, I don't see (and have never seen) the superuser titlebar in Debian Jessie KDE, Gnome or Cinnamon.

[netblue30]

I think it will stay in Jessie like that forever. I don't have it either in Mate in Debian testing.

[gripedthumbtacks]

this issue seems to have reappeared in the latest mate releases

[pemartins1]

I can confirm the issue, using Linux Mint Mate 18.2. Just noticed that Firefox was supposedly being ran as superuser when Firejailed.

[smitsohu]

A possible explanation for the effect is that programs run in PID namespaces and both the programs and Mate's window manager don't know about it.

The PID from inside the sandbox, typically a small number, is used to set _NET_WM_PID, and then probably the window manager checks outside the sandbox if this _NET_WM_PID belongs to the superuser (which it usually does).

[hamishmb]

Can confirm it happens in Mint 19.3 MATE as well (MATE 1.22.2)

[smitsohu]

@hamishmb It's an issue with Marco, MATE's window manager.

See mate-desktop/marco#301