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

[James Tyrer]

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