ConsoleKit entfernen

[bumer]

Guten Tag Forum,

Es gibt ja bereits die folgenden beiden Threads (beide bereits etwas älter):

http://debianforum.de/forum/viewtopic.php?f=29&t=104587
&
http://debianforum.de/forum/viewtopic.php?f=29&t=104587

Trotzdem bin ich noch etwas unsicher wenn es darum geht ConsoleKit zu entfernen. Ich nutze meine Maschine (Wheezy 7.5) ausschließlich alleine und sie läuft auch nicht als Server und es gibt auch keine Remote-Zugriffe. Als WM läuft bei mir IceWM - nutze kein DE. Dann sollte es eigentlich kein Problem das ConsoleKit zu entfernen, oder? Werde ich irgendwelche Einschränkungen erfahren?

Wenn es kein Problem darstellen sollte das Ding zu entfernen:
Reicht dann ein einfaches -aptitude purge consolekit-
oder müssen noch weitere Einstellungen vorgenommen werden?

Grüße,
bumer

[KBDCALLS]

Sollte keine Nebenwirkungen haben, da es ein optional Paket ist.

[smutbert]

consolekit sorgt halt zB auch mittels ACL dafür, dass der momentan lokal angemeldete Benutzer Zugriffsrechte für Peripherie zB Scanner, DVB-T Empfänger,… hat.
Notfalls muss man ohne consolekit manuell mit der Gruppenzugehörigkeit oder mit selbst geschriebenen udev-Regeln für die notwendigen Rechte sorgen.

[bumer]

Danke für die Info!

consolekit sorgt halt zB auch mittels ACL dafür, dass der momentan lokal angemeldete Benutzer Zugriffsrechte für Peripherie zB Scanner, DVB-T Empfänger,… hat.
Notfalls muss man ohne consolekit manuell mit der Gruppenzugehörigkeit oder mit selbst geschriebenen udev-Regeln für die notwendigen Rechte sorgen.

Du meinst also es könnte Probleme mit den Rechten aufgrund der Gruppenzugehörigkeit geben? Ein "sudo" könnte doch bei solchen Vorgängen zur Not & für den Anfang Abhilfe schaffen, oder?

Ansonsten lässt sich die Gruppenzugehörigkeit ja leicht beeinflussen, aber das mit den udev-Regeln klingt wieder nach viel Lesen und Ausprobieren - vielleicht ist das der Aufwand nicht wert - eigentlich stört mich ConsoleKit ja nur, weil es zu viele Threads in htop erzeugt.

[smutbert]

Das ganze über das Erlangen von root-Rechten, egal ob mit su oder sudo, zu lösen, halte ich für keine gute Idee und ein vollkommen unnötiges Sicherheitsrisiko, aber meistens läßt sich das recht einfach mit dem Hinzufügen des Nutzers zu einer Gruppe lösen.
Als Beispiel wie es mit consolekit aussieht und was man ohne unternehmen müßte, hier mein DVB-Empfänger, der einige Gerätedateien erzeugt, ich beschränke mich einmal auf /dev/dvb/adapter0/dvr0 (weil es bei den anderen eh gleich aussieht):

Code: Alles auswählen

$ ls -al /dev/dvb/adapter0/dvr0 
crw-rw----+ 1 root video 212, 1 Sep 17 11:17 /dev/dvb/adapter0/dvr0

Am + hinter den Berechtigungen erkennt man, dass auch eine ACL für diese Datei existiert. Diese wurde von consolkit erstellt, enthält

Code: Alles auswählen

$ getfacl /dev/dvb/adapter0/dvr0
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dvb/adapter0/dvr0
# owner: root
# group: video
user::rw-
user:meinbenutzer:rw-
group::rw-
mask::rw-
other::---

und ermöglicht „meinbenutzer“ sowohl lesenden wie auch schreibenden Zugriff. Diese ACL ginge ohne consolekit verloren.
Wie man aber bei beiden Ausgaben sieht, dürfen auch Mitglieder der Gruppe video lesend und schreibend (rw-) auf diese Datei zugreifen, dh. ohne consolekit müsste ich nur einmal als root

Code: Alles auswählen

adduser meinbenutzer video

ausführen um „meinbenutzer“ zur Gruppe video hinzuzufügen und die Sache hat sich. Bei einem anderen Gerät wäre die Zugehörigkeit zu einer anderen Gruppe notwendig, so ist es bei Scannern meistens die Gruppe scanner.

consolekit erspart es einem zuerst die Gerätedatei zu einem Stück Hardware ausfindig machen zu müssen und dann den/die Benutzer zu dieser Gruppe hinzuzufügen.
Erst wenn die Gerätedatei keiner anderen Gruppe als root gehört, wird es etwas komplizierter und man müsste das mit einer udev-Regel ändern, aber das ist relativ selten der Fall.

[KBDCALLS]

Traut man den Benutzern so wenig zu , das sie die nötigen Berechtigungen nicht selbst setzen können. Da ist ja fast wie bei. Windows.

Ist aber auch nicht gerade so prickelnd was die Webseite dazu schreibt.

ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!

[wanne]

Das einzige was mir fehlt, ist das krandrtray nicht mer funktioniert

[catdog2]

Traut man den Benutzern so wenig zu , das sie die nötigen Berechtigungen nicht selbst setzen können.

Dinge, die einfach so funktionieren wie sie sollen… nein das darf nicht sein! Wie soll man sich denn da noch elitär abgrenzen? Irgendwelche Berechtigungen setzen ist schon kuhl, will ich den ganzen Tag machen, da kann ich mich wie ein richtiger hax0r fühlen.

[scientific]

Traut man den Benutzern so wenig zu , das sie die nötigen Berechtigungen nicht selbst setzen können. Da ist ja fast wie bei. Windows.

Ist aber auch nicht gerade so prickelnd was die Webseite dazu schreibt.

ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!

Da ich auch unlängst darauf gestoßen bin, dass logind ja irgendwie consolekit ersetzen kann/soll/wird... kann ich darauf vertrauen, dass dann ck zur gegebenen Zeit von den Maintainern entfernt wird? Oder muss ich mich darum selber kümmern?

lg scientific

[smutbert]

Also soweit ich das sagen kann, funktioniert bei mir unter jessie seit kurzem alles ohne consolekit und libpam-ck-connector (was natürlich nicht heißt, dass es nicht doch einige Pakete geben könnte, die explizit von consolekit abhängen).

Sorgen würde ich mir bei installiertem consolekit trotzdem keine machen. Upstream gab es die letzte (und mir scheint wenig substanzielle) Änderung im Juli 2013 und davor im März 2012, da scheint es mir angesichts der Tatsache, dass sich die Debian-Maintainer ja offensichtlich noch darum kümmern (letzter Eintrag im Changelog April 2014) unbedeutend, dass sich upstream offiziell keiner mehr darum kümmert.

Sonst fliegen solche Pakete, wenn Bugs auftauchen aus testing und schaffen es damit natürlich auch nicht in das nächste stable. Damit ein Paket dann aber nicht noch längere Zeit in unstable liegen bleibt, kann der Maintainer die Löschung beantragen, so wie es hier zB vor nicht allzu langer Zeit mit mp3gain passiert ist 761847