It's up to them to solve this, MATE apps know nothing about Firejail or Flatpak.

For the record: This is probably a result of PID namespaces, and the effect should be observable with many sandboxing tools (firejail, bubblewrap, flatpack, ...)

The PID from inside the sandbox, often a single digit 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).

I'd suggest you use the XResource extension to query the LOCAL_CLIENT_PID value for the window from the X server rather than trust _NET_WM_PID which may be faked or running inside a different pid namespace. @monsta don't know if you want to reopen given the last couple of comments ?

(I got linked to here from a KDE bug report with a similar problem)

That's not a terrible idea, but blindly switching will break just as many places as it fixes.
Like smplayer which have mplayer and the GUI as separate processes, but deliberately have a NET_WM_PID which is "faked"

shouldnt matter unless one of the separate processes runs as root right?

I wonder if this issue is related to why some of the flatpaks don't fit in with the DE I am using. Kinda like if I were actually running them as root.

The bug is still present on Marco 1.20.3-1 [Debian GNU/Linux 10 (buster)].
End users don't care which team fixes it, @monsta.

I have tried LOCAL_CLIENT_PID
https://stackoverflow.com/questions/37283179/python-pid-to-x11-window-id-using-xresqueryclientids/37309217#37309217

This does not work either for sandboxed applications.

Still a problem for me on Mint 19.3 with Flatpak apps.

Same issue on Linux Mint 20 Mate with Flatpak applications.

4 years have passed and the issue still exists. I just tried telegram with Mint Mate 20 and the taskbar title says "(as super user)" without "telegram" word at all. Will it be fixed one day?

This bug does not present on any other DE or Wayland compositor, so I think it is up to Marco to fix it.

I can't reproduce this, Brackets and libreoffice installed via flatpak from flathub in fedora 32, installation can be done as normal user ;)

Same when i install libreoffice from snapd.

Linux Mint MATE 20.1
Skype from flathub

I too am having this problem. In my case I have a flatpak version of KeePassXC which opens with superuser in the titlebar. I am concerned with this as KeePassXC has access to the internet. This only happens on the Mate desktop. It does not happen for example on XFCE.

Maybe the issue is app-dependent? I see it on Slack and Zoom. MATE 1.26.0, Gtk 3.24.31.

I can confirm this weird behavior with com.jetbrains.IntelliJ-IDEA-Community.
But it seems to be a false positive because it runs as my normal user (rave).

ps aux | grep IntelliJ-IDEA-Community
rave       60707  9.8  2.5 10848068 825680 pts/4 Sl+  14:31   0:25 /app/idea-IC/jbr/bin/java -classpath /app/idea-IC/lib/util.jar:/app/idea-IC/lib/bootstrap.jar:/lib/tools.jar -Xms128m -Xmx750m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -Xmx2048m -XX:ErrorFile=/home/rave/java_error_in_idea_%p.log -XX:HeapDumpPath=/home/rave/java_error_in_idea_.hprof -Djb.vmOptionsFile=/home/rave/.var/app/com.jetbrains.IntelliJ-IDEA-Community/config/JetBrains/IdeaIC2021.3/idea64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.vendor.name=JetBrains -Didea.paths.selector=IdeaIC2021.3 -Didea.platform.prefix=Idea -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main

Same with org.nmap.Zenmap

[rave@mother ~]$ ps aux | grep Zenmap
rave       62802  0.0  0.0 221416   852 pts/5    S+   14:43   0:00 grep --color=auto Zenmap

So it isn't nice but not really a security problem.

Confirmed, the issue doesn't exists when using metacity WM in Mate session.
What the hell is different again comparing marco and metacity....... :/

Can you see if #742 (just merged) fixes this? If so it can be closed

It doesn't seem to fix the issue for flatpaks

The fix is here (merged) #741
So this can be closed.

Opps 741 needs to be merged. I will do that later.

now it is merged :)

@raveit65, @CuBeRJAN I've compiled Marco from source (commit 2540175e5a5b15e65aecaf94a29f208e6a3836c9) and launched org.kde.okteta, the issue appears to be solved. ✅
Thank you, I'll stay tuned for the next release on Debian. 👋🏻

Hello, Vorta Flatpak runs as "superuser". Any suggestion on what i should or shouldn't do would be appreciated. Or am i in wrong place? Our distro package Vorta version 0.8.3-1 is messed up too, reason i went to flatpak, should i find different backup software?

Still present in Linux Mint 21.3 MATE. Fresh system install with first time online updates. All Flatpak apps that are launched from user account, has "as superuser" in title. Problem persists also after built-in flatpak 1.12.7 replacing to 1.14.6 from Flatpak PPA.

Same (still present) on Ubuntu 24.04 with ubuntu-mate-desktop installed.
flatpak 1.14.6-1
marco 1.26.2-4build4

Same on Ubuntu 22.04 with mate-desktop installed.

Microsoft dropped the support for skype deb package... so it's a shame that after many years the bug is still present.

Unfortunately still present in 24.04.1 / MATE 1.26.1

@lukefromdc I see. Thanks for this info 👍

Still an issue on Fedora 41's official spin with MATE 1.28.2, confirmed running marco rather than compiz

I don't think much is going to happen on this one until either old team members become active again
or new folks join the team. I cannot do all of this solo, and this is one of the bugs that does not exist
in my own systems, in this case because I do not use flatpak and don't even have it installed.

Check security of flatpak progs with flatseal https://flathub.org/apps/com.github.tchx84.Flatseal
Or install it via dnf in fedora.
As i told here before those progs do not run as root.

They do not run as a regular app though.

Well, yes (except there shouldn't be anything running as root) but if users see false-positive "as superuser" all day they don't notice it and ignore it.

Maybe add a separate label for Flatpak/Firejail? Like this pseudopython:

if app_uid is not user_uid:
  if app_uid == 0:
    add_label("as superuser")
  else:
    add_label("sandboxed")

@tidux the problem with you suggestion is that it fixes the wrong problem. The uid check isn't broken by itself, it is the way the uid of an window is query that is broken.

Well then fix your shitty window manager. It's been eight years, guys.

@lukefromdc Just to be clear I know you guys try to do a good job but everyone has bills to pay so thanks for what you guys have done but unfortunately there's only so much you can do

Anyways, I hope this bug gets fixed one day but I agree we should never talk smack about people who willingly use their time to build anything FLOSS

Thank you guys 👍