View previous topic :: View next topic |
Author |
Message |
tomiondrums n00b
Joined: 02 Feb 2007 Posts: 54 Location: Unterleinleiter
|
Posted: Tue Jun 23, 2009 11:04 pm Post subject: Gruppenmitgliedschaft und NIS/LDAP |
|
|
Hi!
Die Datei /etc/group legt ja bekanntlich fest, wie eine Gruppe heißt, welche GID sie hat und wer alles Mitglied in ihr ist. Ein Benutzer der die Audio-Devices am Rechner verwenden will, sollte in der Gruppe 'audio' sein, damit ihn sein System das auch lässt....
Jetzt kommt es aber vor, daß man einen Teil seiner Benutzer im Netzwerk zentral verwalten will/muß und benutzt dazu NIS oder LDAP oder ähnliches. Auch dort gibts das Konzept mit den Gruppen und ihren Mitgliedern. Ich möchte beispielsweise die Mitglieder der Gruppe 'audio' zentral mit LDAP verwalten und hab deswegen unter Anderem meinen Benutzer 'tomi' auf dem LDAP zu einem Mitglied von 'audio' gemacht. (Daß der Client das auch mitkriegt zeigt mir 'getent group', indem es den Benutzer 'tomi' als eines der Mitglieder von 'audio' anzeigt)
Soweit so schön!
Der Haken an der ganzen Sache ist nur, daß ich als Benutzer 'tomi' in der Praxis nicht die Rechte bekommen, die mir als 'audio'-Mitglied zustehen, d.h. z.B. ich kann von der KDE aus keine Musik hören, die Laustärkeregelung nicht benutzen und bekommen X Fehlermeldungen diesbetreffend.
Ich glaube mittlerweile daß es sich hierbei um ein Problem im Zusammenhang mit PAM handelt, weil ich schon früher, als ich noch mit NIS rumgemurkst hab, mir die Zähne an dem Problem ausgebissen hab. Im Moment behelfe ich mir indem ich wie gesagt, die Gruppen alle trotzdem lokal (/etc/group) anlege und dort auch die über LDAP importierten Nutzer eintrage, was natürlich LDAP vollkommen sinnfrei macht.
Woran könnte das o.g. Problem liegen? Was kann ich dagegen tun?
Vielen herzlichen Dank schonmal für alle Ideen!
MfG
Tom |
|
Back to top |
|
|
tomiondrums n00b
Joined: 02 Feb 2007 Posts: 54 Location: Unterleinleiter
|
Posted: Wed Jun 24, 2009 11:35 am Post subject: |
|
|
ich hab grad die ganze Sache auch nochmal vereinfacht und folgendes ausprobiert:
- ein Verzeichnis /testdir erstellt
- dessen Lese/Schreibrechte auf die Gruppe beschränkt und es mit 'chown root:audio /testdir' Root und der Gruppe audio übereignet
'ls -la' sagt jetzt:
Code: |
...
d---rwx--- 2 root audio 4096 Jun 24 00:41 testdir
...
|
die Zeile für die Gruppe 'audio' in der '/etc/group' gelöscht (wofür mich udev bei Neustart gleich mal heftig bestraft hat... :-/ )
mich mit getent versichert, daß mein Benutzer auch in der Gruppe 'audio' drin ist
Code: |
# getent group |grep 18
dhcp:x:1018:
audio:*:18:anja,gabi,reinhold,tomi
|
(Der Benutzer 'tomi' wird vom LDAP-Server bezogen und ein Login damit auf dem Client funktioniert wunderbar)
Probiert ob ich mit 'tomi' auch in das Verzeichnis reinkomme:
Code: |
tomi@dual / $ cd testdir/
bash: cd: testdir/: Permission denied
|
Wie man sieht passt da was nicht... Woran kanns liegen?
Meine /etc/pam.d/system-auth
Code: |
auth required pam_env.so
auth required pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_ldap.so use_first_pass
account sufficient pam_ldap.so
account required pam_unix.so
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password required pam_unix.so try_first_pass use_authtok nullok md5 shadow
password sufficient pam_ldap.so use_authtok use_first_pass
session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_ldap.so
|
Kanns auch sein, daß ich noch an einer anderen Datei in /etc/pam.d was hätte ändern sollen?
Meine /etc/nsswitch.conf
Code: |
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $
passwd: files ldap
shadow: files ldap
group: files ldap
#passwd: compat
#shadow: compat
#group: compat
hosts: files ldap dns
#hosts: files dns
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
|
|
|
Back to top |
|
|
STiGMaTa_ch Veteran
Joined: 28 Dec 2004 Posts: 1686 Location: Rüti ZH / Schweiz
|
Posted: Wed Jun 24, 2009 3:01 pm Post subject: |
|
|
tomiondrums wrote: | Meine /etc/nsswitch.conf
Code: |
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $
passwd: files ldap
shadow: files ldap
group: files ldap
|
|
Aendert es was, wenn du ldap vor files nimmst in nsswitch.conf?
Code: |
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $
passwd: ldap files
shadow: ldap files
group: ldap files
|
Lieber Gruss
STiGMaTa _________________ Ich bin Schuldknappe. Das bedeutet ich bin immer an allem Schuld. Und das nicht zu knapp! | Der alltägliche Familienwahnsinn auf meinem BLOG |
|
Back to top |
|
|
tomiondrums n00b
Joined: 02 Feb 2007 Posts: 54 Location: Unterleinleiter
|
Posted: Thu Jun 25, 2009 7:46 am Post subject: |
|
|
das kann ich leider nicht machen (es bringt im Übrigen auch nix), weil dadurch udev beim Bootvorgang in eine Endlosschleife (bzw. einen Lock) gerät (udev fragt Gruppeninfos ab -> kontaktiert zuerst LDAP -> LDAP benötigt Netzwerkanbindung -> Netzwerk ist noch down -> Netzwerk soll gestartet werden -> Anfrage an udev -> ....). Ziemlich haarig das ganze.
Es auch sehr merkwürdig, daß ja die Benutzerauflösung über LDAP einwandfrei funktioniert. Sogar die Änderung von Passwörtern seitens eines Benutzers läuft einwandfrei. Nur dieses elende Gruppenzeug krieg ich nicht hin und das schon seit Jahren.
Außerdem versteh ich nicht so ganz, was das mit dem '*' und dem 'x' bei 'getent group' hinter dem Gruppennamen soll. Wenns eine Entsprechung zur /etc/group sein sollte, dann müsste dort ja das verschlüsselte Gruppenpasswort stehen. In meiner lokalen /etc/group siehts bei Gruppen ohne Passwort aber folgendermaßen aus 'gruppenname::0815:mitglied1,mitglied2'. Heißt '*' oder 'x' wohl auch, daß die Gruppe einfach kein Passwort hat, oder ist das ein Fehler? |
|
Back to top |
|
|
tomiondrums n00b
Joined: 02 Feb 2007 Posts: 54 Location: Unterleinleiter
|
Posted: Thu Jun 25, 2009 1:28 pm Post subject: |
|
|
Ich hab's!
Der Teufel sitzt wie immer im Detail:
Das genannte Problem wird nämlich weder von einer der hier genannten Dateien noch von PAM oder sonst einem Fehler in der NSS-LDAP-Software verursacht. Im Gentoo-OpenLDAP-Leitfaden steht, daß man auf den Clients in der /etc/ldap.conf unter anderem folgende Zeilen eintragen soll:
Code: | pam_member_attribute memberuid |
Die Schreibung des Attributs passt aber nicht mit den im Verzeichnis abgelegten Daten zusammen, weil dort heißt das Attribut nämlich memberUid
Wenn man außerdem noch Code: | nss_connect_policy persist | einträgt und neustartet, sodaß NSS die Infos über die Gruppen neu vom Server abholen muß, dann läufts. |
|
Back to top |
|
|
Tiberian n00b
Joined: 03 Jan 2008 Posts: 13
|
Posted: Thu Jun 25, 2009 5:04 pm Post subject: |
|
|
tomiondrums wrote: | das kann ich leider nicht machen (es bringt im Übrigen auch nix), weil dadurch udev beim Bootvorgang in eine Endlosschleife (bzw. einen Lock) gerät (udev fragt Gruppeninfos ab -> kontaktiert zuerst LDAP -> LDAP benötigt Netzwerkanbindung -> Netzwerk ist noch down -> Netzwerk soll gestartet werden -> Anfrage an udev -> ....). Ziemlich haarig das ganze.
Es auch sehr merkwürdig, daß ja die Benutzerauflösung über LDAP einwandfrei funktioniert. Sogar die Änderung von Passwörtern seitens eines Benutzers |
Dagegen hilft ein bzw. Code: | nss_initgroups_ignoreusers ldap,avahi,haldaemon,dbus,smmsp | in der ldap.conf
Dann is das beim reboot auch weg. Zumindest war es bei mir so. Leider is die Zusammenarbeit zwischen dem udev team und dem team dass pam_ldap und nss_ldap pflegt irgendwie nicht so gelungen
Grüße
Tiberian |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|