http://bugzilla.opensuse.org/show_bug.cgi?id=1205607 http://bugzilla.opensuse.org/show_bug.cgi?id=1205607#c2 --- Comment #2 from Fabian Vogt <fabian@ritter-vogt.de> --- This is actually a separate development from the original approach to including that inside file://. While the previous design had a small helper used by file://: KIO -> file:// -> helper This one is a separate protocol which internally uses file:// as root: KIO -> admin:// -> helper -> KIO -> file:// https://apachelog.wordpress.com/2022/08/04/kio-admin/ has a short explanation.

So this seems to be the release of the long standing efforts to generalize privileged file operations in KDE. It has about 1.500 lines of C++ code.

I tried to give some advice to the upstream devs but it seems it didn't help much on the design level. There is only a single polkit authorization rule 'org.kde.kio.admin.commands' for _all_ of the file operations. And given this, there are naturally no transparent authentication messages. This means end users will once more authenticate unknown file system operations in unknown locations. And based on the `auth_admin_keep` Polkit setting an arbitrary number of arbitrary follow-up operations can ensue.

The operations are split over separate DBus paths, so I imagine they could be split in polkit as well.

Design wise kio-admin is now more or less a copy of what gvfs-admin is for Gnome. Given this model future uses of these facilities are also beyond our monitoring. We can attempt to check how much gvfs-admin is already used in Gnome software to get a better feeling for how much that is. I have a gut feeling that for KDE the future use will be more extensive than it is or will be on Gnome. The KDE development culture seems to embrace the use of frameworks and integration more than Gnome does.

FWICT this is meant to be used directly by the user, not internally by applications.

Since accompanying the upstream development process also didn't help getting an improved design I don't see much else possibilities here than to accept it the way it is. I will discuss with the rest of the team first, though. A basic review of the code is also still required.

While this is an independent implementation by someone who was not directly involved in the other (meanwhile abandoned?) approach, this is more flexible because it's not intertwined with core KIO code. Requesting design changes should be much easier here. -- You are receiving this mail because: You are on the CC list for the bug.