Web lists-archives.com

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




On 04/24/2013 02:53 AM, Duncan wrote:
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.


<SNIP>

I do think that there are reasons to run GUI processes as root. For example: KUser always needs to be run as root.

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).

Since processes are arranged as a tree, I doubt that two X sessions would know anything about each other. My issue, which I stated, that isn't important, is that the: "startkde" script is failing to detect a running user D-Bus so it starts another one that I don't think is needed meaning that the user X session is running with 2 user D-Buses if started from: "startx". But, I got: KDM running now so that is no longer an issue.

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.)

Yes, and apparently different users running inside the same X session also require their own D-Bus.

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.)

Actually, I think that I have accurately diagnosed the problem by commenting out the: dbus-launch command in the root user's .bash_profile script and then trying to start konqueror with "xhost +" and "su -" in a Konsole. Without the D-Bus running, it crashes and I get a message:


konqueror(3209)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)


Doing:

export $(dbus-launch)

does fix the problem and Konqueror then starts.

So, I think we know the problem. That is why I guessed at the hack using Bash to do a login session for root and start a D-Bus for that session.

This works in a Konsole or a 'desktop' file:

	kdesu -c "bash -l -c <command>"

So, I see it as a bug in KDESU. Exactly what the hack does depends on how KDESU works.

It appears odd that each new use of KDESU requires a _new_ D-Bus daemon. And, since it appears that KDESU starts the applications as 'exec' that the: "dbus-daemon" processes just keep building up. But that problem is really a consequence of my hack although it would need to be addressed in any bug fix for KDESU. Since it is started as 'exec' the "bash" process is replaced by the app being run and there is no build up of "bash" processes.

--
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
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.