No, it’s most definitely not. A GUI is many times more dangerous than CLI tools.
Your typical GUI application will, in no particular order:
read files and write them using the existing set of permissions
talk to session services
talk to system services
load shared modules
load and interpret fonts, image data, and other files that have various, unknown provenance
All of that, will be performed by something in the ballpark of a few millions lines of code that have never been properly audited for security.
Let me stop you there, because unless you wrote all the code you’re actually running as root, then you have no idea what the code is actually doing. Just because you know not to delete a file when running something as an administrator it does not mean you have any knowledge about what the application you’re using is doing—which is why you should never run GUI applications as root. Not because the user is “dangerous”, but because the code may very well be, and you can’t know that.
Why do you think every new technology for application development has “sandboxing” as a line item?
Yes, that is correct. That is why it is best practice in the terminal to still use tools like polkit and containerization to heavily restrict what actually runs as root, rather than just running sudo on random programs.
If you want to edit files as root properly, then follow Jason’s advice and use admin:/// in nautilus, gnome-text-editor, gedit, or whatever other applications support it. (Or use a terminal.) Then only the file that you actually want to edit will be modified as root, and you won’t cause damage to other files that you don’t realize the application is modifying (e.g. XDG user dirs, GTK bookmarks, thumbnail cache, and who knows what else). I don’t dare open nautilus as root myself to see what all goes wrong, but suffice to say that it’s unsupportable.
I’m not so sure, but, well, you’ve been warned. Next time an application fails to start unless it’s run as root, or a feature is broken when not root, you’ll want to search for root-owned files in your home directory before reporting a bug. Normally there should never be any, but your experience is going to be be different.
That’s not to mention more basic breakage that you’ll encounter, like anything that requires a session bus will not work when you’re root…
I usually use a file management application as root to view system-level files and directories. In the past, Midnight Commander, which was run in the terminal, was used for this purpose, now it is Double Commander, or Krusader. I usually only use the built-in viewer of these file managers, or the built-in text editor for editing, if a system file needs to be modified. Of course, I also use nano in the command line. So far there has been no problem with this.
What does any of that have to do with future customizability of Gnome? I don’t follow.
You need to do something in a system directory? Open Files, press Ctrl+L and for example type admin:///etc and you’re in the /etc directory with root permission. Need to edit a file there? In the Files window double-click a file and the text editor opens it with root permission. As others explained you don’t need to run the file manager or text editor as root for this, just use the admin:// scheme. No need to modify desktop entries.
And if you want to change desktop entries you can do that however you want: use a menu editor of your choice, or copy the desktop entry file from the system dir (/usr/share/applications/) to your data dir (~/.local/share/applications/) and edit it there—that’s the same thing a menu editor does.
Gnome has stopped supporting the creation of desktop icons for some time now, favoring Dash instead. However, I still miss the right mouse button context menu, where you could customize a few things in the properties.
OK. It still seems related to development/debugging. Is it correct ? If so, what is your goal? Help GNOME app development? Do you work with source code? Or do you just want to reproduce crashes and see an app’s messages/errors in the terminal?
I think these are average user needs, not developer or tester needs at all. On Xfce, when you click on a desktop icon with the right mouse button, the properties submenu is also part of the fcontext menu that appears, I think not specifically for advanced users.
I don’t know how it is on XFCE. The fact that such options are present in other desktop environments does not mean that these options are intended for the average user.
The average user doesn’t need to run a GUI application from the terminal: it’s rare to do so, so it doesn’t need to be exposed, and it can be done by opening the terminal. However, you may not know what the name of the application is if you want to do this (for example, a knowledgeable user wants to launch Document Viewer to see if there are any errors but does not know that it’s called evince) - but that’s another issue.
What kind of start command are you referring to? Run the app in the background? Open it directly in a specific location (e.g. nautilus which opens a specific location instead of the home directory, Evolution which always opens the Tasks pane instead of opening the last visited pane)?
Editing desktop entries is not meant for users. Those are part of the app and they get installed into /usr, only developers should write/edit that when shipping the package.
Just copying the desktop file you want in ~/.local/share/applications/ and editing it, is not hard to do/understand even for a basic user.
Anyway, my only use case to launch a GUI application as root is using Meld to diff few customized system files in /etc after updates (’.pacnew’ files on Archlinux) and partially apply some of the updates. I’ve never found a usable way to do that with the commandline. What would be the ‘right’ way to do that?
Doing that can have unintended consequences, if you change something important like nautilus or gnome-control-center. It is dangerous for users to do that.
Try to use the admin:// backend, if it does not work then file a bug with Meld.
BTW the classic way to do this is to use sdiff -o. I am surprised Arch Linux does not have a wrapper around that tool.
I’ll try admin::// backend, though it will probably add a slowdown in my workflow:
sudo meld file1 file2 → launch meld, open… admin:// for file1 admin::// for file2
(I suppose, I will test it this evening).
Didn’t knew sdiff. Tried on msys2. Better than plain diff, but not really human friendly…
meld admin:///file admin:///file2 works and I can save changes to files in system dirs that way.
It does show a weird “File None is being compared to itself” notice bar for each file, but everything seems to work. I don’t use meld often enough to say but maybe if it’s out of place you can suggest an improvement to meld for handling the admin:// scheme.
If we assume that you are right, then there is no need for the terminal application in a graphical desktop environment either. However, an open source Linux distribution is mostly used by those who know how to use an operating system better than average, and not only on the graphical interface, but also under the hood with the help of issuing commands. This distinguishes an open-source, for example, Linux-based system from a closed-source system (Windows, macOS, etc.)
Where did you hear that? It is not correct, closed-source systems (e.g. Windows, macOS) also have command lines. What distinguishes an open-source system is that the source code is available publicly for developers to use.