su sometimes works, but badly.
xdg-su -c '{binary}'
There’s also kdesu, provided by kde-cli-tools.
Also, always check to see if the privilege escalation utility you’re using has an option to preserve environment, otherwise it will use root’s environment, and that is often not desirable.
Also, if the app you want to run as root has a valid use case for this, consider submitting a feature request for it to implement privilege escalation. Running an entire app as root can be quite a bad idea.
5 Likes
The simplest answer is: you shouldn’t run GUI programs as root.
A more complicated answer:
TL;DR is: you shouldn’t.
7 Likes
Unfortunately, dolphin just doesn’t prompt for privilege escalation via the GUI (polkit) when I need to interact with files owned by a user with higher permissions than me.
Indeed, I can file feature requests. But I need to edit some files immediately. I think I’ll get repetitive strain injury if I give Graham more bugs to triage this week.
How do they differ? I tried gksudo, but I can’t find what package provides it, even with cnf.
I don’t see a fundamental problem.
If something on my system is malware, it can get root access pretty easily by just faking a partition mounture prompt. If malware is on my system, it’s already compromised – my browser should have prevented it being download, VirusTotal should have notified me, and Comodo should have quarantined it already.
However, primarily, I shouldn’t have been stupid enough to download it.
Buggy apps on the other hand are definitely less likely to screw with something irreparably when not run as the superuser specifically, but most stuff isn’t protected by the superuser, so it doesn’t prevent much damage.
If these were serious problems, we’d see more users on Windows destroy their systems by running explorer as Administrator, but they don’t.
You really should. The fact you have to ask about it on a forum should be a clue to you that you don’t really know much about it, and that it would be wise to listen to the advice of others.
But sometimes one has to learn on one’s own mistake, I guess 
Linux is not Windows. The analogy does not work.
There definitely are bugs that have a disastrous effect. A somewhat unrelated example: just a single unlucky space in a bash script can wipe out large sections of your filesystem:
With GUI programs, you’re not only running the program as root, you’re running millions of lines of code of dependencies as root, most of which wasn’t designed to be run as root and wasn’t tested properly running as root. Sure, most of the time it won’t be a problem. Most of the time.
Also, there is an issue you’ve completely overlooked: with the permissions in the user’s home directory. This has happened to me, many years ago. Some of the files in my user’s .config directory were created by the root user, which means they were inaccessible to the normal user, which created bugs that were very difficult to troubleshoot.
In any case, it’s not a use case that was foreseen by the software developers, it goes against the fundamental Linux concept of separation of privileges, it can have bad side effects, and it is not necessary.
6 Likes
Missing polkit support in Dolphin is already a well known bug/feature request (no need to file a bug report, there already is one).
For now there is KIO Admin | đź’ş Blog
System / KIO Admin Worker · GitLab
Although you should know what you are doing if you try this.
4 Likes
It is no better the other way around. If e.g. the normal user switches from KDE/Plasma to the Linux Console and back, he is asked e.g. by polkit-kde-authentication-agent for the password of root, allegedly to update the SMART values. This begs the question, how should the user know the root password and why wasn’t he asked for it directly at startup, when logging into the GUI KDE/Plasma?
Another funny thing is, no user could log in to his KDE/Plasma after root removed /bin/rm temporarily. There one can only advise each user to bring its data in time in security.
But I plead for keeping the accounts root/user basically separate. In my opinion there is nothing against a su --login in the terminal. There are excellent editors and tools for the command line and so you stay in practice, because if the system breaks down the GUI is not available.
So how am I to graphically manipulate filesystem objects owned by users with higher permissions than myself, if so?
Typically, you should not be messing with directories not owned by your user. Why would you ever need or want to do that, if your permissions are correctly set up?
Sure, from time to time, you might need to edit some config file owned by root, but you don’t need a file manager for that, Kate has polkit support, or use a TUI text editor like Vi or Nano.
I don’t really see a use case for anything else. If you need to access files and directories owned by some other user, set up group ownership and permissions accordingly, that’s why they exist.
But if you really need to do more than that, you should use a shell in a terminal emulator, or a TUI file manager, like Ranger. If you need to do this on a regular basis, something is not right and I am sure there is a better way to do it.
3 Likes
- Getting
scriptlogs created when running a shell as the superuser (common practice). - Adding snapshots to
/.snapshots/and editing/.snapshots/grub-snapshot.cfgto include them.
However, more importantly than either of those things, the ability to see file details, such as size, without having to use su dolphin:
Windows’s explorer provides this.
Per
It doesn’t work if invoked directly via
Very few can, much less want, to use TUIs for basic functionality. That’s surely a silly solution, not least because it isn’t one – it just puts the development and usage burden on TUI file managers instead. How does that make sense?
Are you on openSUSE? Their security team deliberately patches out the polkit support from Kate.
He is using openSUSE (some sort of testing or unstable version).
In this case its not about openSUSE patching polkit support out of Kate since I can’t open that file either (running Arch). AFAIK polkit works only for saving files. Since you usually have read permissions but not write permissions it works fine. This file (/etc/shadow) has no read permissions from a normal user like other files in /etc.
Not sure if that is intentional or missing feature / work in progress.
1 Like
Yes, @Herzenschein, I am using cpe:/o:opensuse:tumbleweed:20230601.
Does a bugzilla.opensuse.org and/or bugs.kde.org ticket (to your knowledge) exist for this already?
I ask because
demonstrates that kate’s problem may be vaguely more difficult to create a feature request for via bugs.kde.org if I am experiencing two issues, one caused by kate, and the other caused by OpenSUSE Factory.
This is the bit I don’t get.
2 Likes
@tracyanne, I think I’d presumed that accounts on Linux-based OSes work similarly to those on NT-based ones, in that there can be a very defined hierarchy of accounts with differing permissions. As an example:
AdministratorNTAUTHORITY/SYSTEMTrustedInstaller
Is this not so?
It might be the usage of words like “hierarchy” and “higher” that are confusing there - at least within the traditional user/group account model, the only “hierarchy” is root (unconfined by file ownership or permissions) and everyone else (confined by ownership and permissions).
At any rate, this is a help thread that was marked as solved almost two years ago - if there are still related questions or issues to be raised, I’d think they would be better served in their own topics. That way, folks who can help will see an unsolved topic with a more specific title and can jump in 
Often, I mark a thread as solved, come to back to it, and realise I was wrong. I don’t mind someone correcting me 10 years after I’ve posted the question - these conversations are designed to be asynchronous. Creating another with an identical topic and question seems redundant.
@johnandmegh, can’t they have differing levels of permissions? In which case, it appears equivalent to Windows’s implementation.