[Pkg-utopia-maintainers] Bug#747105: Bug#747105: Bug#747105: policykit-1: depends on systemd - breaks libpolkit-backend

[Woody]

Michael Biebl wrote:
> Am 25.05.2014 17:15, schrieb Michael Biebl:
>> Am 25.05.2014 15:32, schrieb Woody:
>>> Laurent Bigonville wrote:
>>>> Woody wrote:
>>>>> I see also a broken behaviour. I am doing a dual boot - with and
>>>>> without systemd.
>>>>> Till the libpolkit-backend has been linked against systemd, it has
>>>>> worked just fine.
>>>>>
>>>>> The problem is now that backend is trying to blindly use systemd, and
>>>>> fails if systemd is not running as init. With that change the user
>>>>> authentication for network-manager or pcmanfm mounting are broken -
>>>>> there is just a pcmanfm msgbox "Not Authorized".
>>>>>
>>>>> So *libpolkit-backend should first try to verify if systemd is an
>>>>> init program, and if not - do not try to use it for authentication* -
>>>>> it will definitely fail - so there is no point doing so.
>>>>>
>>>>> I understand that running without systemd is not a typical Debian
>>>>> installation, but dependence on systemd should not be a mandatory for
>>>>> Debian breaking everything either.
>>>> The only thing that policykit expects is a registered logind session
>>>> (you can use loginctl command to check if it exists), not systemd as
>>>> PID1. Moreover, network-manager also using logind for session tracking
>>>> since 0.9.8.8-1.
>>>>
>>> My point is that if I overwrite the libpolkit-backend 1.0.5-5 with the
>>> .so from 1.0.5-4 - the network manager and pcmanfm manage to
>>> authenticate (probably using consolekit)
>>>>> It is an important bug.
>>>> Could you please check if you have a logind session registered. Also
>>>> which DM are you using to login?
>>> Laurent, no DM. Imagine an embedded system starting X first, asking
>>> questions (and services ;-0) later...  Here is the logincmd data :
>>>
>>> /woody> loginctl list-sessions
>>>     SESSION        UID USER             SEAT
>>>          c1       1000 user             seat0
>>>
>>> 1 sessions listed.
>>>
>>>   /woody> loginctl session-status c1
>>> c1 - user (1000)
>>>             Since: Mon 2014-05-19 12:41:21 EDT; 5 days ago
>>>            Leader: 1475 (su)
>>>              Seat: seat0; vc1
>>>               TTY: /dev/tty1
>>>            Remote: user root
>>>           Service: su; type tty; class user
> And please don't login as root and use su to start the X session, but
> login as your regular user and then run startx, so the session is
> properly tracked.
>
> Michael
>
>
Michael, thanks, you describe how a regular Linux session is (should be) 
established.
However I am creating a single user embedded environment without a need 
for login.
There is no login and no DM.
The init process runs as root, starts via "su -c user" an X session.
I have selected to run X on vt2 because there often are extra 
kernel/warnings messages on vt1. Probably I could run X on vt1, however 
it would have hide them.
None of these is "illegal" (I think 8-) )

The current Debian policykit change is forcing systemd as the only 
solution for system init. That may be a valid policy, but unless it is 
confirmed to be a sane choice for the future - I consider it a broken 
backward functionality... So it is a decision to make...

Thanks, Woody