Save as root with Kate and friends on openSUSE

[pallaswept]

In Kate, Kwrite, Kdevelop, etc, if you try to save a file and you do not have permission, you will be prompted to authenticate an account that does. So, you can ‘save as root’.

On openSUSE distros, this is disabled. I see a question about this every week or so, but never quite enough details to fix it… so I’m posting a solution here. I hope this is helpful. This solution does get a little nerdy (creating and maintaining your own package, adding your repository, etc) so if that’s not for you, you might consider using the flatpak of the application instead.

Be aware that openSUSE do disable this for a reason, there are security concerns. They don’t mind if you have this feature, they just can’t say it’s safe to package up for everyone. Refer to the bug linked below for more info.

From the changelog (of the kf5 package):

on May 15 13:53:15 CEST 2017 -

• Revert upstream feature as disliked by the security team (boo#1033055)
  • 0001-Revert-KAuth-integration-in-document-saving-vol.-2.patch
  • 0002-Revert-KAuth-integration-in-document-saving.patch

The referenced bug: (please don’t make requests and spam the devs there, make a new bug if you want to discuss it… but don’t, because they know)
https://bugzilla.opensuse.org/show_bug.cgi?id=1033055

Thus endeth my disclaimers Pls don’t shoot the messenger.

The openSUSE package which needs to be patched to allow this is kf6-ktexteditor. In the spec file, You need to add a build dependency on KF6Auth, change -DENABLE_KAUTH:BOOL=FALSE to TRUE, and include the extra files. These two files (just these two, no other sources req’d) in a package on OBS (or locally) will do the trick:

_link:

<link project="openSUSE:Factory" package="kf6-ktexteditor">
  <patches>
    <apply name="enable_kauth.patch" />
  </patches>
</link>

enable_kauth.patch:

Index: kf6-ktexteditor.spec
===================================================================
--- kf6-ktexteditor.spec (revision 10)
+++ kf6-ktexteditor.spec (revision 4)
@@ -41,6 +41,7 @@
 BuildRequires:  pkgconfig
 BuildRequires:  cmake(EditorConfig)
 BuildRequires:  cmake(KF6Archive) >= %{_kf6_bugfix_version}
+BuildRequires:  cmake(KF6Auth) >= %{_kf6_bugfix_version}
 BuildRequires:  cmake(KF6Config) >= %{_kf6_bugfix_version}
 BuildRequires:  cmake(KF6GuiAddons) >= %{_kf6_bugfix_version}
 BuildRequires:  cmake(KF6I18n) >= %{_kf6_bugfix_version}
@@ -90,7 +91,7 @@
 
 %build
 %cmake_kf6 -DBUILD_QCH:BOOL=TRUE \
-           -DENABLE_KAUTH:BOOL=FALSE
+           -DENABLE_KAUTH:BOOL=TRUE
 
 %kf6_build
 
@@ -109,6 +110,11 @@
 # TODO split
 %dir %{_kf6_plugindir}/kf6/parts
 %{_kf6_plugindir}/kf6/parts/katepart.so
+# KAuth files
+%_libexecdir/kf6/kauth/kauth_ktexteditor_helper
+%{_datadir}/dbus-1/system-services/org.kde.ktexteditor6.katetextbuffer.service
+%{_datadir}/dbus-1/system.d/org.kde.ktexteditor6.katetextbuffer.conf
+%{_datadir}/polkit-1/actions/org.kde.ktexteditor6.katetextbuffer.policy
 
 %files -n libKF6TextEditor6
 %license LICENSES/*

Note that trying this right now will fail, because KF6.10 is in QA. It’ll work again in a day or two when that snapshot is released.

[rockandstone]

Or you can open Dolphin in “super user mode” iirc, then proceed from there.

[pallaswept]

That’s a commonly advised workaround, and it might get the job done, but I don’t recommend it. When you do that, the entire dolphin process is run as the root user, which is why it launches kate as the same user, and then kate also runs with the root account. Everything you do, will be done as root. It’s probably even less secure than the thing openSUSE decided was not secure enough.

It’s widely recommended to not do this (run GUI apps as root), because it can and occasionally does break stuff - I know this from personal experience. So, not only is it insecure to do this, it’s also bad for the general health of the system - and having tried this method and been stung, I feel that this is actually the greater concern. I’m not worried about someone taking control of the physical machine, but if I break it myself, that’s a realistic problem.

When we use the above mechanism, it’s only the act of saving the file, which is given root permission - kate continues to run with your own user account. Everything you do, will be done as you. You keep your themes and configuration of kate and ownership of your config files and all that good stuff.

Also, we don’t need to know our future intention to save as root, before we open it, and add an extra step to the process of opening it. So, the usability is better this way.

As I described in OP, it’s not for everyone, so I’m not trying to ‘my way or the highway’ here, but that way ain’t good.

[krake]

@pallaswept

That’s a commonly advised workaround, and it might get the job done, but I don’t recommend it. When you do that, the entire dolphin process is run as the root user, which is why it launches kate as the same user, and then kate also runs with the root account.

This is true, however, there is also an “Admin Mode” that you can activate in Dolphin (View → Act as Administrator).

This only starts a KIO helper as root, essentially a handler for “admin:/” URLs.

If you open a file through that the editor application also runs as the user and simply uses that URL as the load/save location.

It is even possible to use “admin:/” URLs in applications “Open File” or “Save File” (and Save As) dialogs.

No idea when this was introduced as I am so used to doing “root” editing in a shell

[pallaswept]

kio-admin is also not supported on openSUSE. I feel like this thread covers the sentiment well

https://old.reddit.com/r/openSUSE/comments/1gm9zcm/one_hundred_canadian_dollars_for_anyone_who_makes/

Maybe I should make a similar thread to this one, for that.

[krake]

Ah, interesting.

I wonder how OpenSUSE users are editing files as root then.

Can’t have access to sudo or similar tools as those would allow even more operations with a single authorisation than kio-admin.

Explicit root login?

[rockandstone]

@krake

I wonder how OpenSUSE users are editing files as root then.

Since they have Dolphin in “super user mode”, I suppose this is their official GUI way, otherwise why would they offer it.

[ben2talk]

When using Dolphin, I usually would hit F4 to pull up the terminal, then you can do sudo edit yourfile in the terminal.

However, by the sounds of it, I would not use KDE with OpenSUSE unless I really strongly agreed with their decision not to support polkit…

Hence, I use Manjaro (reliable now for 8 years).

[rockandstone]

@ben2talk

When using Dolphin, I usually would hit F4 to pull up the terminal, then you can do sudo edit yourfile in the terminal.

You are missing the fact that sudo is not configured in OpenSUSE

[ben2talk]

So you really are stuffed - couldn’t you use doas? How do you do this stuff?

OpenSUSE really is weird.

[pallaswept]

@krake

I wonder how OpenSUSE users are editing files as root then.

Uncomfortably
Jokes aside, we do have sudo, kdesu and pkexec and all that… I believe the officially supported method is either sudoedit in a terminal or to save it elsewhere and then launch a shell and sudo install or sudo mv the file to the desired location.

FWIW this thread got me to check the status on this and there have been very recent updates just days ago, so the light at the end of the tunnel bears closer…

[rockandstone]

@ben2talk

How do you do this stuff?

I guess they do su and su -.

[ben2talk]

So basically you’re ruled out of using KDE’s text editor, need to go with ‘su’ and then maybe use nano or something like gedit which doesn’t use polkit.

Still, easy to do from Dolphin’s terminal.

Not my top subject, TBH, but is this only OpenSUSE that thinks it’s not secure enough? That’d be a real dealbreaker for me.

[krake]

@rockandstone

Since they have Dolphin in “super user mode”, I suppose this is their official GUI way, otherwise why would they offer it.

I have to say that is hard to believe

One issue with kio-admin (and gvfs-admin) is apparently that they allow multiple file operations once authorized.

Running a full file manager as user super would do this as well plus all the issues of running a GUI application that way.

@rockandstone

You are missing the fact that sudo is not configured in OpenSUSE

Right, that makes sense.
Or at least not in a way that allows you to open an editor or a shell.

@ben2talk

So you really are stuffed - couldn’t you use doas? How do you do this stuff?

My guess would be that all system level config is administrated through YAST (or its successor).
That used to be the recommended way back when I was using SuSE and could now simply be enforced my removing all manual editing options.

@pallaswept

I believe the officially supported method is either sudoedit in a terminal

That makes sense as that would require you to specify the files you want to affect before permission is granted.

And probably only needed for the rare cases when the sysadmin tool (whatever yast is called nowadays) does not already provide an interface to do the actual thing

[rockandstone]

@ben2talk

OpenSUSE really is weird.

Fundamentally they are not wrong, on the contrary sudo was not meant to be so insecure giving full rights using the user’s password i.e. “ITMOTB”'* (to quote Paul Arnote ) did and many distros (wrongfully imo) blindly copied without informing the user, but to be pre-configured in a way to give the normal user only limited access to certain commands.

'*

In The Manner Of The Buntus

[pallaswept]

I just wanna be clear that it wasn’t my intention to dump on openSUSE too hard here. Many (I wish I could say all) of their contributors, maintainers, etc have been very kind to me and I would hate to be disrespectful of that. I just wanted to share a more verbose set of directions to fix this.

That being said, if you feel the need, speak your mind, because the current situation sucks for lots of users and has nerds like me posting threads like this, so people are gonna have feels. I’ll try and be objective.

@ben2talk

is this only OpenSUSE that thinks it’s not secure enough? That’d be a real dealbreaker for me.

Yes, it’s only them, but that’s likely because OpenSUSE is the only distro that checks this stuff.

OpenSUSE really is weird.

So … you’re not wrong But maybe it’s a good kind of weird?

In their defence, it is cool that they’re doing extra security checks, and I know that SUSE’s customers do appreciate it. And they provide an easy-to-use package build service (OBS) where stock things can be relatively easily replaced with fully-functional packages.

Eg., if you have an OBS account, you could branch a package which is already patched as per this thread, install the package to your system, and add the repository for automatic updates, in 5 clicks. Installing from an existing branch or further installations to other machines would be 3 clicks. Or you could script any of that if clicks aren’t your bag.

On the other side of the fence, these issues have been in a bike shed for years, and I personally don’t subscribe to the notion that security should come at the expense of functionality, if anything I believe the opposite. Opinions aside, I know for a fact that this security lockdown has driven many users to do insecure things to get around it.

Swings and roundabouts? I don’t know. I see both sides of this conundrum, so I really don’t believe that either side should ‘win’, and that’s what’s happening for the time being. But they’re fixing that. Soon^tm

@rockandstone

You are missing the fact that sudo is not configured in OpenSUSE

LOL I did forget about that!
It’s not configured out of the box, but you still get the upstream config, where you can login to root, using root’s password. The configuration is packaged for those who want it, in sudo-policy-sudo-auth-self and sudo-policy-wheel-auth-self, which allow you to use your own password if you have the appropriate group memberships. ITMOTB

[Herzenschein]

What is this about sudo not being configured by default? I don’t recall ever needing to enable sudo.

The ktexteditor thing is the sole gripe I have with openSUSE. I used to use rpm-build to rebuild the ktexteditor source package with the patch (something you can do on RPM distros that leads to an actual full-blown package installable with zypper, which is great).

[pallaswept]

@Herzenschein

What is this about sudo not being configured by default? I don’t recall ever needing to enable sudo.

Sorry, I did say that, I was quoting the post above, but I guess a more accurate way to say it is that OOTB, it is not configured to accept the user’s password “in the manner of the 'buntus”, but requires root’s (the target user’s) password.

[klirtax]

For a one-time action, start Kate and optionally open the desired file(s) in Konsole as root:

user@localhost:/> su
Password:
localhost:/ # kate /etc/fstab /etc/crypttab /etc/default/grub  # three files example
THIS IS POTENTIALLY INSECURE!
To edit files as root please use:
SUDO_EDITOR=kwrite sudoedit <file>
localhost:/ #

Now these files are open in a Kate instance that is run as root (confirm: Kate > F4 > whoami) and you can create/add more files if needed, and save to wherever you like (if other perm’s permit, of course).

To have root Kate always available, you can create a permanent entry in Application launcher: “Edit Applications…” > duplicate the Kate entry > tab “Advanced” > “run as different user” > username “root.”
EDIT: Make this very obviously different from the user Kate, e.g., change the name from “Kate” to “Kate AS ROOT”, and optionally change the icon. The time spent here is well invested…

And more general, for other applications: Some use a polkit command, e.g., Back In Time: run as user with backintime-qt or as root (w/password prompt) with /usr/bin/backintime-qt_polkit %f.