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
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
