[GH-ISSUE #258] (as superuser) in title bar

gitea-mirror commented

2026-05-05 05:15:46 -06:00

Owner

Originally created by @SYN-cook on GitHub (Jan 23, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/258

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

Originally created by @SYN-cook on GitHub (Jan 23, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/258 _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

gitea-mirror

2026-05-05 05:15:46 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:15:50 -06:00

Author

Owner

@ssokolow commented on GitHub (Jan 26, 2016):

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

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

@ssokolow commented on GitHub (Jan 26, 2016): 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.)

gitea-mirror commented

2026-05-05 05:15:52 -06:00

Author

Owner

@SYN-cook commented on GitHub (Jan 27, 2016):

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

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

@SYN-cook commented on GitHub (Jan 27, 2016): 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.

gitea-mirror commented

2026-05-05 05:15:53 -06:00

Author

Owner

@ssokolow commented on GitHub (Jan 27, 2016):

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:

Check if the Python os.getlogin() call returns a different user than os.getresuid()
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)
Try running setsid between the su and terminal call to see if running the program in a new session helps.
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.
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.)

@ssokolow commented on GitHub (Jan 27, 2016): 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.)

gitea-mirror commented

2026-05-05 05:15:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 27, 2016):

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.

@netblue30 commented on GitHub (Jan 27, 2016): 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.

gitea-mirror commented

2026-05-05 05:15:56 -06:00

Author

Owner

@SYN-cook commented on GitHub (Jan 27, 2016):

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

@SYN-cook commented on GitHub (Jan 27, 2016): 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

gitea-mirror commented

2026-05-05 05:15:57 -06:00

Author

Owner

@ssokolow commented on GitHub (Jan 27, 2016):

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.

@ssokolow commented on GitHub (Jan 27, 2016): 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](https://github.com/GNOME/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.

gitea-mirror commented

2026-05-05 05:15:59 -06:00

Author

Owner

@SYN-cook commented on GitHub (Jan 27, 2016):

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

@SYN-cook commented on GitHub (Jan 27, 2016): Sorry, I don't know if this helps: http://sourcecodebrowser.com/libgtop/2.22.0/procuid_8h.html#aff3a9a5a3afb876e35bad14e850a56e6

gitea-mirror commented

2026-05-05 05:16:00 -06:00

Author

Owner

@ssokolow commented on GitHub (Jan 27, 2016):

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

It calls glibtop_get_proc_uid_s
glibtop_get_proc_uid_s calls _glibtop_get_procinfo to retrieve the struct containing the uid member we care about.
_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.

@ssokolow commented on GitHub (Jan 27, 2016): 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.

gitea-mirror commented

2026-05-05 05:16:02 -06:00

Author

Owner

@ghost commented on GitHub (Feb 7, 2016):

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

@ghost commented on GitHub (Feb 7, 2016): For me, MATE shows as if programs are running as root. XFCE and KDE, however, don't.

gitea-mirror commented

2026-05-05 05:16:04 -06:00

Author

Owner

@0xBRM commented on GitHub (Feb 7, 2016):

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

@0xBRM commented on GitHub (Feb 7, 2016): @amarildojr KDE 4.14 here and it shows firefox running (as superuser).

gitea-mirror commented

2026-05-05 05:16:06 -06:00

Author

Owner

@ghost commented on GitHub (Feb 8, 2016):

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

@ghost commented on GitHub (Feb 8, 2016): @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.

gitea-mirror commented

2026-05-05 05:16:08 -06:00

Author

Owner

@SYN-cook commented on GitHub (Sep 19, 2016):

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.

@SYN-cook commented on GitHub (Sep 19, 2016): 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.

gitea-mirror commented

2026-05-05 05:16:10 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 19, 2016):

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

@netblue30 commented on GitHub (Sep 19, 2016): I think it will stay in Jessie like that forever. I don't have it either in Mate in Debian testing.

gitea-mirror commented

2026-05-05 05:16:12 -06:00

Author

Owner

@gripedthumbtacks commented on GitHub (Sep 28, 2017):

this issue seems to have reappeared in the latest mate releases

@gripedthumbtacks commented on GitHub (Sep 28, 2017): this issue seems to have reappeared in the latest mate releases

gitea-mirror commented

2026-05-05 05:16:14 -06:00

Author

Owner

@pemartins1 commented on GitHub (Oct 1, 2017):

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

@pemartins1 commented on GitHub (Oct 1, 2017): I can confirm the issue, using Linux Mint Mate 18.2. Just noticed that Firefox was supposedly being ran as superuser when Firejailed.

gitea-mirror commented

2026-05-05 05:16:15 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 2, 2017):

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

@smitsohu commented on GitHub (Nov 2, 2017): 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).

gitea-mirror commented

2026-05-05 05:16:17 -06:00

Author

Owner

@hamishmb commented on GitHub (Jun 12, 2020):

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

@hamishmb commented on GitHub (Jun 12, 2020): Can confirm it happens in Mint 19.3 MATE as well (MATE 1.22.2)

gitea-mirror commented

2026-05-05 05:16:18 -06:00

Author

Owner

@smitsohu commented on GitHub (Jun 26, 2020):

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

See mate-desktop/marco#301

@smitsohu commented on GitHub (Jun 26, 2020): @hamishmb It's an issue with Marco, MATE's window manager. See mate-desktop/marco#301

Rows
Columns

[GH-ISSUE #258] (as superuser) in title bar #183