[kde-linux] KDESU doesn't work again with 4.10

[Duncan]

James Tyrer posted on Tue, 23 Apr 2013 12:33:50 -0700 as excerpted:

> The KDESU window open, I enter the root password, click the button, the
> window disappears, and nothing further happens.  No Konqueror and no
> error box.

By policy I don't run any root (or for that matter other user) X apps at 
all here, and at some point I actually uninstalled kdesu/kdesudo and the 
related plumbing, which wasn't working when I uninstalled it in any case, 
thus encouraging making my to that point de-facto policy an official one, 
so I've been staying out of this (sub?)thread until now.  However, while 
I do NOT claim to know that much about what I'm talking about in this 
case, based on what I've picked up from various and nebulous sources...

AFAIK kde has switched entirely over to the new policykit authorizations 
now, and no longer "supports" the old su/sudo style authorizations at all.

"Supports" is in scare-quotes, because AFAIK that's the official status.  
To the best of my knowledge, the old-style authorization *CAN* still 
work, but due to the X-session authorizations involved in addition to the 
usual file permissions needed for ordinary console-based apps (and also 
dbus/policykit, but see below for that), getting/keeping X-based other-
user/super-user apps working is actually rather complicated, and while kde 
and the various distros /used/ to ship all that in generally working 
condition, these days what they ship in that regard is all policykit 
based, leaving the old-style sudu-and-x-based solutions 100% to the user 
to setup and maintain, should they insist on doing so.

*ADDITIONALLY*, the new policykit style authorizations use dbus, etc, not 
just XAUTH/fileperms, which of course requires application-level dbus/
polkit support, and I guess some apps, likely including kde's konqueror, 
etc, are now dbus-dependent to the point were the NO LONGER WORK with 
simply XAUTH/fileperms/kernel-caps based support -- they require working 
dbus support as well.  For these dbus/policykit enabled apps (including I 
believe konqueror/dolphin/etc), therefore, the policykit method is now 
the ONLY working method, because they expect dbus support and without it 
working correctly they'll either not initialize at all or will quickly 
crash if the do.

Which was the problem I stumbled over when I last tried using them here.  
The policykit end apparently wasn't setup correctly, because I didn't 
/want/ for example my X-based user being able to mess with system-global 
clock settings (which are managed at the system level by ntp, so there's 
no reason for an  user to /need/ to set them, so I think I had disabled 
my user's system-level policy-kit authorizations early on.  For a few 
versions, the old xauth/fileperms probably still worked for other things 
(say konqueror), until they dropped support for it as well, but I used it 
so seldom I didn't catch where that broke, and by the time I did finally 
catch it, it was a done deal.

And at that point, with the functionality broken, it was just easier to 
create an official policy out of what had been de-facto policy for quite 
some time, than it was to go learn the whole new policykit style 
management and carefully configure appropriate policykit permissions for 
my X user, to keep various bits of that I /might/ use working, without 
enabling the bits of it (like system-level-clock control) that would 
otherwise be working by default, but which I definitely did NOT want the 
X-based user to be able to mess with.


So here's current status to the best of my understanding:

AFAIK, konqueror and etc (and probably most kde-based apps, thus kwrite, 
etc, plus kdesu and thus anything enabled via kdesu) are all dbus enabled 
now, requiring it to function, and thus *REQUIRE* working alternate-user 
policykit, etc, support, in ordered to work at all as alternate-user.  
Policykit, etc, is thus the only way they'll work at all, these days, 
there's no longer the old style su/sudo support for them, period.

Assuming the traditional/"legacy" xauth and su/sudo plumbing is still 
operational, traditional/"legacy" non-policy-kit-enabled xauth/fileperms/
caps-only apps *SHOULD* continue to work, *PROVIDED* they're other-user-
enabled using a non-policy-kit-based launch-method.  But kdesu/kdesudo 
are out as such a method, as they're now policykit enabled and if that's 
broken for other-user-enabling, they're broken for it as well.


FWIW, my usual method of handling super-user/other-user tasks in X/kde, 
invoking konsole as my normal user and "legacy" sudoing from it to my 
admin user in the konsole/CLI, that admin user having unrestricted 
("legacy") sudo access to everything else, continues to work as it always 
has.  But of course, now due to deliberate policy, that only allows me to 
run CLI and "semigui" ncurses/slang style clients within konsole -- I 
don't have (same-X-session) X-based access to other user X-based apps at 
all.

That said, I discovered quite by accident a couple months ago... that I 
can run startx from within that "legacy" sudo-ed admin-user konsole 
session, and it'll start a SECOND, entirely separate X-session as that 
admin user on the next available VT, allowing me to use the normal ctrl-
alt-Fx VT-switching keys to switch between VTs including both the normal-
user and admin-user entirely separate X-sessions, each in their own VT 
along with the usual CLI based VTs, the system console logger VT, etc.


Meanwhile... @ JT, addressing another dbus-related comment from earlier 
in the thread:  It wasn't clear from that comment, JT, whether you 
realized this bit about dbus or not, but as opposed to the above which 
I'm unsure about, this bit I'm quite sure on:

On a normal system there will be at least two and possibly more DBUS 
sessions running: The system (basically root) session, normally started 
at boot by the init-scripts (FWIW part of the controversy surrounding 
systemd is that it requires just that -- unlike traditional init-systems, 
it REQUIRES a working dbus and will normally start one early in the boot 
process... the implication being that soon a system-dbus will be assumed, 
and within a few years it'll be impossible to start most system services 
without it), and a user-session dbus, started either at user-session init 
(if login is via gui/xdm method), or with startx (if login is at the CLI, 
with users running startx to start X).

So normally you'll have your system dbus session, and the user dbus 
session -- two separate dbus sessions running.  Of course if you're 
running multiple X sessions, you'll probably have multiple user dbus 
sessions running as well, particularly if the X-sessions are for 
different users.  (I'm not sure whether separate X-sessions of the same 
user can be handled with the same user dbus session or whether they 
require separate dbus sessions as well, but obviously, different user X-
sessions will require different dbus sessions, one for each different 
user X-session.)


What that all means is that (AFAICS) you have three alternatives:

1) Get familiar enough with dbus and policykit to manage all these 
permissions/sessions in addition to the normal xauth and file-based 
permissions.

2) Declare a policy as I have, X-based apps run as the normal user, 
period.  All super-user based access is CLI based and any alternate user 
X-based apps run in their own X-session as that alternate user.  (Yes, 
that could include running a root-user X-session, if you want to run root-
user X-based apps, altho I could not and will not recommend that.)

3) Go back to a generic/distro-setup environment, such that the default 
permissions are all managed for you and everything "just works"... except 
where it doesn't, in which case, you file a bug with the distro or etc.  
(But I somehow doubt either you, JT, or I, could ever be entirely happy 
with that, or we'd not be running gentoo and LFS to begin with.  Dale... 
I'll let him speak for himself, but there's other reasons to run gentoo, 
so maybe he's content to do the generic gentoo/kde policykit permissions, 
and for him they're "just working", whether he actually understands the 
implications of the involved policykit permissions, or not.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman