| 1 |
On 16/01/14 19:39, Neil Bothwick wrote: |
| 2 |
> On Thu, 16 Jan 2014 10:19:22 -0600, Canek Peláez Valdés wrote: |
| 3 |
> |
| 4 |
>>>> Helmut is still using consolekit. Are you still using consolekit? |
| 5 |
>>> Yes, it's the default for kdm so it is enabled on both computers. |
| 6 |
>> I don't think it will be the default for much longer; it's unmaintained |
| 7 |
>> code which sooner or later will start to bitrot. Unless someone steps in |
| 8 |
>> and starts taking care of it. |
| 9 |
> Quite likely, but for now it is the default and in use on both systems in |
| 10 |
> question. |
| 11 |
> |
| 12 |
>>>> I have no idea if consolekit is relevant here, but Canek has been |
| 13 |
>>>> telling us that consolekit is abandonware and we should stop |
| 14 |
>>>> depending on it. |
| 15 |
>>> That's part of the drive to put everything in systemd, which I do not |
| 16 |
>>> use. |
| 17 |
>> Fact is, nobody is maintaining ck; from its homepage[1]: |
| 18 |
>> |
| 19 |
>> "ConsoleKit is currently not actively maintained. The focus has shifted |
| 20 |
>> to the built-in seat/user/session management of Software/systemd called |
| 21 |
>> systemd-logind!" |
| 22 |
> That's what I was paraphrasing above. I checked the latest status on that |
| 23 |
> page before replying. |
| 24 |
> |
| 25 |
>> That message has been there for months; in general ck kinda still works, |
| 26 |
>> although it never really solved the problem of properly tracking user |
| 27 |
>> sessions, which is why everybody involved with it quickly jumped ship to |
| 28 |
>> logind, where the problem is properly solved. |
| 29 |
> The issue for many is that logind is so closely tied to systemd. |
| 30 |
> |
| 31 |
>> However, as the interfaces in the stack evolves, unmaintained code like |
| 32 |
>> ck will simply stop to work. ConsoleKit uses dbus heavily, and with the |
| 33 |
>> introduction of kdbus[2] and the inevitable changes that will happen to |
| 34 |
>> dbus, combined with nobody taking care of ck, I don't think it will keep |
| 35 |
>> working much longer. |
| 36 |
> That's a reasonable prediction. |
| 37 |
>> Ubuntu and Debian (now that is seriously discussing which modern init |
| 38 |
>> system to use) have been discussing an alternative, API compatible |
| 39 |
>> implementation of logind, but I don't know if it has got nowhere. I |
| 40 |
>> think that has more future than ck, but again, nobody (AFAIK) has |
| 41 |
>> stepped in and do the heavy coding. |
| 42 |
> Leaving aside my concerns about systemd, I am not happy with the "all |
| 43 |
> eggs in one basket" direction things seem to be taking. Whatever happened |
| 44 |
> to tolls doing one job and doing it well? |
| 45 |
> |
| 46 |
>> Independently, though, I think is safe to say that ConsoleKit is a dead |
| 47 |
>> end. |
| 48 |
> In the future, most probably. but right now it is the preferred option |
| 49 |
> for KDM. |
| 50 |
> |
| 51 |
> |
| 52 |
|
| 53 |
Right, only GDM (the display manager for GNOME) has dropped ConsoleKit |
| 54 |
support so far, that I know, in versions 3.8 and later |
| 55 |
So other than GNOME, ConsoleKit is still a go -- thus, compatible with |
| 56 |
OpenRC based system |
| 57 |
|
| 58 |
For KDE it might be something else than dbus-glib that needs a |
| 59 |
recompile, I'd imagine something like kdelibs or polkit-kde-agent, or both |
| 60 |
It could be something else too, but setting the suid bit on |
| 61 |
dbus-daemon-launch-helper is stupidest idea ever, that *really* allows |
| 62 |
anyone to gain root |
| 63 |
However if you run a machine with single user and no open ports on the |
| 64 |
machine whatsoever, the attack vector is propably very small, but I still |
| 65 |
wouldn't do it |
| 66 |
|
| 67 |
- Samuli |
Archives