pam_groups ersetzen

[Rüdiger Kupper]

Siehe #3211.
pam_groups gilt als veraltet und soll ersetzt werden. Erste Anwendungen unterstützen es schon nicht mehr. Dad wirkt sich etwa auf unseren winestarter aus.

[Rüdiger Kupper]

Gestern fiel mir auf, dass mein derzeitiger Workaround für den µC-Kurs (#3211) möglicherweise auch die Lösung für dieses Problem sein könnte:

Mit den udev-Regeln kann man nämlich auch ganz einfach festlegen, welcher Gruppe die dynamisch angelegten Devices gehören. Standardmäßig ist das die Gruppe dialout, die nur lokal bekannt ist. Unsere Nutzer erhalten ihre Gruppenzugehörigkeiten aber über LDAP (daher kommt unser Problem).

Mögliche Lösungen

1. die aktuelle Lösung (pam_groups) ist veraltet und funktioniert nicht mehr zuverlässig
2. früher hatte ich das Problem mal dadurch gelöst, dass ich von Hand eine LDAP-Gruppe mit dem selben Namen und der selben GID eingerichtet habe. Nachteile:
   • die GID der lokalen Gruppe muss im LDAP auch noch verfügbar sein (nicht garantiert)
   • geht nur, wenn die GID auf allen Rechnern die selbe ist (ist sie bei uns natürlich, weil wir Images verteilen)
   • bricht zusammen, falls sich die lokale GID ändert (dürfte aber selten sein)
3. Wenn wir die udev-Regel so abändern, dass z.B. der USB-Adapter z.B. der Gruppe p_usbadapter gehört, dann können wir einfach ein Projekt in der Schulkonsole mit diesem Namen anlegen. Dann können wir über die Schulkonsole steuern, wer auf den USB-Adapter zugreifen darf. Wenn das µC-Projekt das einzige ist, das ihn braucht, kann man das Device sogar dem Projekt p_mikrocontroller_kup übereignen, das ich für den Kurs nutze.

Das müsste eigentlich gut funktionieren -> ausprobieren.

Ob wir auf diese Weise alle Einträge der pam_groups ersetzen können, weiß ich nicht, weil sich nicht alle auf dynamische Devices beziehen – oder doch? So sieht der Inhalt von /etc/security/group.con derzeit aus:

*;*;*;Al0000-2400;dialout,cdrom,floppy,audio,dip,video,plugdev,scanner,vboxusers
*;*;administrator;Al0000-2400;adm,admin,lpadmin
*;*;pgmadmin;Al0000-2400;adm,admin,lpadmin

Die Einträge in der ersten Zeile beziehen sich alle auf dynamische Devices (was ist dip?). Allerdings ist es auch etwas hohl, ein Schulkonsolenprojekt für cdrom und floppy anzulegen. Hm …

[bau]

Nun ist es also soweit:
Des Problem tritt beim WindowsXP-Starter auf. Startet man VirtualBox einfach über den Starter, so funktionieren die USB-Ports (Irgendwie erkennt der die Gruppenzugehörigkeit), startet man den Starter für Windows oder virtualbox aus dem Terminal, so wird die Gruppenzugehörigkeit nicht erkannt.

Die User müssen in der Gruppe vboxusers sein, das ist bei uns die Gruppe 120 (auf paedml sind die Gruppen bis 110 belegt, geht also). Wir können also entweder den User beim Login in die Gruppe vboxusers reinstecken, dann managed der Client das selber - oder alle User auf dem paedml in eine neu anzulegende LDAP-Gruppe stecken (haben wir das schon einmal gemacht?).

[bau]

Auf dem Client geht eigentlich ganz einfach:

• /etc/sudoers.d/kepler--virtualbox-add-user-to-group-vboxusers

    # Fuer die VirtualBox-XP-VMS muessen User das Script als root benutzen duerfen
    # um beim Login in die Gruppe vboxusers zu kommen
    ALL ALL = NOPASSWD: /usr/local/sbin/kepler--add-user-to-group-vboxusers
  

• /usr/local/sbin/kepler--add-user-to-group-vboxusers

     usermod -aG vboxusers $SUDO_USER
  

• In der .profile kommt der Aufruf zu spät (nach einem weiteren Logout/Login tut es erst):

   sudo /usr/local/sbin/kepler--add-user-to-group-vboxusers
  

  Wo kann man das unterbringen, damit die gnome-shell die neuen Gruppen auch mitbekommt?

[bau]

ToDo für neues Image:

• /etc/sudoers.d/kepler--LAMPP kepler--virtualbox-registry-patch
  entfernen das ist nicht mehr notwendig

[bau]

Interessant: der GDM3 kann vor dem Login Scripe ausführen: ​https://unix.stackexchange.com/questions/450835/how-to-execute-command-before-user-login-on-linux

Da wäre z.B. /etc/gdm3/Init/Default

[Rüdiger Kupper]

Replying to bau:

ToDo für neues Image:

• /etc/sudoers.d/kepler--LAMPP kepler--virtualbox-registry-patch
  entfernen das ist nicht mehr notwendig

Erledigt.

[bau]

Dummerweise kommen die gdm3-Starter alle irgendwie für die Benutzerverwaltung zu spät (komisch, ich dachte, die kommen VOR der Session) - der Benutzer wird damit der neuen Gruppe zugeordnet, das wird aber erst nach einem Logout/Login erfahrbar.

Was aber ging:

• Benutzer in neue Gruppe packen (usermod -aG)
• Beobachtung:
  • id gibt die neu Gruppenzugehörigkeit NICHT aus
  • id Benutzername hingegen schon
  • offenbar hat die Linux-Benutzerverwaltung das Ganze noch nicht mitbekommen

• newgrp - 
  

  lädt angeblich die Benutzerverwaltung neu, startet bei mir aber eine neue Shell, in der dann die Gruppenzuordnung stimmt. Leider passen in der neuen Shell die Variablen (export) nicht mehr, so dass ich keinen Connect zum X-Server erhalte. Wenn ich die exports von Hand reinkopiere, dann kann ich virtualbox starten, bin in der korrekten Gruppe und habe die USB-Geräte :-)
• Wie kann man nach dem Befehl newgrp - der neuen Shell am schnellsten beibringen, wo das X-Windows erreichbar ist?