Hi Liste, Ich administriere den Linux Server der Azubis bei uns in unserer Firma. Auf dem Server werden auch die HOME- Verzeichnisse der Benutzer gespeichert die per /etc/exports freigegeben werden. da wir alle Azubis den Umgang mit Linux lernen sollen, hat jeder Azubi einen eigenen PC und ist sein eigener Admin. Um meine Linux Kentnisse zu erweitern habe ich den Azubi- Server jetzt um einen NIS- Dienst erweitern, damit die Azubis sich von jedem PC aus anmelden können. Jetzt das Problem: Wenn ich das /home -Verzeichnis per /etc/export freigebe, kann ein Azubi sich einen Benutzer anlegen (nur auf seinem eigenen PC natürlich), der die UID eines anderen Benutzers auf dem Azubi- Server schon hat. Dadurch erhält er Schreib- und Leserechte auf ein Verzeichnis, das ihm nicht gehört. Wie kann ich dennoch das /home -Verzeichnis freigeben, ohne dass andere User sich die Home- Verzeichnisse anderer User aneignen (So etwas wie "root_squash" für Lokale User)? MFG Sven Schiwek -- _______Sven Schiwek_________________________________________________ | e-mail: sven.schiwek@gmx.net | www: http://sven-s.purespace.de | | sven.schiwek@web.de | http://www.azubi.ais-ag.de | |________________________Have a lot of Fun___________________________|
Hi Sven On Fri, Aug 24, 2001 at 08:47:13AM +0200, Sven Schiwek wrote:
Wenn ich das /home -Verzeichnis per /etc/export freigebe, kann ein Azubi sich einen Benutzer anlegen (nur auf seinem eigenen PC natürlich), der die UID eines anderen Benutzers auf dem Azubi- Server schon hat. Dadurch erhält er Schreib- und Leserechte auf ein Verzeichnis, das ihm nicht gehört. Wie kann ich dennoch das /home -Verzeichnis freigeben, ohne dass andere User sich die Home- Verzeichnisse anderer User aneignen (So etwas wie "root_squash" für Lokale User)?
/home/luser luserkiste(rw,all_squash,anonuid=501,anongid=501) wobei all_squash alle zugriffe mit dem unonymous user maskiert und anonuid und anongid diesen user näher spezifiziert. Das ist afaik ziemlich exakt ein Beispiel aus man exports, hättste auch selber lesen können. -- MfG. Falk
Falk Sauer wrote:
Hi Sven
On Fri, Aug 24, 2001 at 08:47:13AM +0200, Sven Schiwek wrote:
Wenn ich das /home -Verzeichnis per /etc/export freigebe, kann ein Azubi sich einen Benutzer anlegen (nur auf seinem eigenen PC natürlich), der die UID eines anderen Benutzers auf dem Azubi- Server schon hat. Dadurch erhält er Schreib- und Leserechte auf ein Verzeichnis, das ihm nicht gehört. Wie kann ich dennoch das /home -Verzeichnis freigeben, ohne dass andere User sich die Home- Verzeichnisse anderer User aneignen (So etwas wie "root_squash" für Lokale User)?
/home/luser luserkiste(rw,all_squash,anonuid=501,anongid=501)
wobei all_squash alle zugriffe mit dem unonymous user maskiert und anonuid und anongid diesen user näher spezifiziert.
Das sollte das eigentliche Problem (Zugriff auf ein fremdes Verzeichnis) aber IMHO nicht lösen. Wenn ich mittels showmount -e <server> die Liste der exportierten Verzeichnisse auf <server> erfahre, dann kann ich diese als root mounten. Der Zugriff auf die gemounteten Daten erfolgt dann mit der UID des jeweiligen Nutzers, den ich ja ebenfalls als root entsprechend lokal anlegen kann. (Ich komme ja nicht als anonymous, sondern mit meiner UID des lokalen Systems.) Wenn Dein Vorschlag greift, dann werden ALLE Anfragen auf den nobody-Account gemappt, d.h., auch von den Rechnern/Usern, die eigentlich Zugriff auf ihre /home-Verzeichnisse erhalten sollten (das Mapping via NIS wird ja auch hier ausgeschaltet). Die Ursache liegt mehr in einem Design-Problem von NFS: kommt ein Request mit der entsprechenden UID, dann habe ich Zugriff. Aber nichts hindert mich daran, als root auf einem Client mir einen entsprechenden Account zu generieren. Als NFS "geboren" wurde ging man eben davon aus, das root immer ein besonders vertrauenswürdiger Geselle ist und ein Unix-Server nicht mal eben von jemandem nebenbei administriert wird (oder gar auf einem Notebook ins LAN geklinkt wird). Die Antwort darauf sollte Secure-NFS liefern, das sich aber wohl nie so richtig durchgesetzt hat. (Mehr darüber im Klassiker: "NFS und NIS" von Hal Stern, O'Reilly). Ich würde als Lösung/Workaround vorschlagen, die /home-Verzeichnisse per SAMBA freizugeben und via smbmount anzubinden, da hier wenigstens ein Passwort für den Zugriff auf den Server notwendig ist (was allerdings recht unkomfortabel sein dürfte, da ich beim Mounten/Booten des Clients ja nach dem Kennwort gefragt werde.) Mögliche Alternative (als Gedankenansatz, ungeprüft!!): Automounter oder Konqueror (oder andere grafische Tools). Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
Am Freitag, 24. August 2001 19:03 schrieb Dirk Hebenstreit:
[Problem: Verzeichnisse per NFS exportieren, dass nur der Besitzer Zugriff erhält, nicht aber andere Rechner/Nutzer]
Die Ursache liegt mehr in einem Design-Problem von NFS: kommt ein Request mit der entsprechenden UID, dann habe ich Zugriff. Aber nichts hindert mich daran, als root auf einem Client mir einen entsprechenden Account zu generieren. Als NFS "geboren" wurde ging man eben davon aus, das root immer ein besonders vertrauenswürdiger Geselle ist und ein Unix-Server nicht mal eben von jemandem nebenbei administriert wird (oder gar auf einem Notebook ins LAN geklinkt wird). Die Antwort darauf sollte Secure-NFS liefern, das sich aber wohl nie so richtig durchgesetzt hat. (Mehr darüber im Klassiker: "NFS und NIS" von Hal Stern, O'Reilly).
Ich würde als Lösung/Workaround vorschlagen, die /home-Verzeichnisse per SAMBA freizugeben und via smbmount anzubinden, da hier wenigstens ein Passwort für den Zugriff auf den Server notwendig ist (was allerdings recht unkomfortabel sein dürfte, da ich beim Mounten/Booten des Clients ja nach dem Kennwort gefragt werde.) Mögliche Alternative (als Gedankenansatz, ungeprüft!!): Automounter oder Konqueror (oder andere grafische Tools).
Hallo Dirk, hallo Leute, gute Idee (manchmal taugen auch Micro$oft-Protokolle etwas ;-) Wie wäre es mit mount -t smbfs -o rw,username='benutzer',password='kennwort' //server/freigabe /mountpoint Das sollte sich auch in /etc/fstab eintragen lassen... Allerdings kann AFAIK (ungetestet) jeder Nutzer des jeweiligen Rechners durch Eingabe von mount die mount-Optionen, also auch das SMB-Password abfragen ;-( Als Alternative: den obigen mount-Befehl per sodo in der ~/.profile des jeweiligen Benutzers ausführen (Freigabe der kompletten mount-Zeile via "visudo" als root, Beschreibung siehe manpage). Da lernen die Azubis wenigstens was... Diesen Tip habe ich übrigens recycelt ;-) (siehe unten) Gruß Christian Boltz ----- Original Mail: [gekürzt] ----- Re: Anfaengerfrage : Windows-Netzwerkressource unter Linux mounten von Falk Gebauer [Freitag, 10. August 2001 09:28] Versuchs doch mal so: mount -t smbfs -o rw //DarkStar-1/etShares/DarkStar_1/'freigegebenes Verzeichnis' /'dein mountpoint' mit Passwort: mount -t smbfs -o rw,username='benutzer',password='kennwort' //DarkStar-1/etShares/DarkStar_1/'freigegebenes Verzeichnis' /'dein mountpoint'
Christian Boltz wrote:
Am Freitag, 24. August 2001 19:03 schrieb Dirk Hebenstreit:
[Problem: Verzeichnisse per NFS exportieren, dass nur der Besitzer Zugriff erhält, nicht aber andere Rechner/Nutzer]
Die Ursache liegt mehr in einem Design-Problem von NFS: kommt ein Request mit der entsprechenden UID, dann habe ich Zugriff. Aber nichts hindert mich daran, als root auf einem Client mir einen entsprechenden Account zu generieren. Als NFS "geboren" wurde ging man eben davon aus, das root immer ein besonders vertrauenswürdiger Geselle ist und ein Unix-Server nicht mal eben von jemandem nebenbei administriert wird (oder gar auf einem Notebook ins LAN geklinkt wird). Die Antwort darauf sollte Secure-NFS liefern, das sich aber wohl nie so richtig durchgesetzt hat. (Mehr darüber im Klassiker: "NFS und NIS" von Hal Stern, O'Reilly).
Ich würde als Lösung/Workaround vorschlagen, die /home-Verzeichnisse per SAMBA freizugeben und via smbmount anzubinden, da hier wenigstens ein Passwort für den Zugriff auf den Server notwendig ist (was allerdings recht unkomfortabel sein dürfte, da ich beim Mounten/Booten des Clients ja nach dem Kennwort gefragt werde.) Mögliche Alternative (als Gedankenansatz, ungeprüft!!): Automounter oder Konqueror (oder andere grafische Tools).
Hallo Dirk, hallo Leute,
gute Idee (manchmal taugen auch Micro$oft-Protokolle etwas ;-)
Nur, das SMB kein M$-Protokoll ist (nur ein "assimiliertes - Urheber ist eher IBM).
Wie wäre es mit mount -t smbfs -o rw,username='benutzer',password='kennwort' //server/freigabe /mountpoint
Das sollte sich auch in /etc/fstab eintragen lassen... Allerdings kann AFAIK (ungetestet) jeder Nutzer des jeweiligen Rechners durch Eingabe von mount die mount-Optionen, also auch das SMB-Password abfragen ;-(
Als Alternative: den obigen mount-Befehl per sodo in der ~/.profile des jeweiligen Benutzers ausführen (Freigabe der kompletten mount-Zeile via "visudo" als root, Beschreibung siehe manpage). Da lernen die Azubis wenigstens was...
Jepp, das liest sich gut! Das Problem mit dem Passwort in Klarschrift beim mount-Befehl ist uns auch schon mal unangenehm aufgestoßen :-/ Deine Lösung kommt jetzt erstmal in die Archivkiste (man weiß ja nie ;-) Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
Hallo Dirk, hallo Leute! Am Samstag, 25. August 2001 22:10 schrieb Dirk Hebenstreit:
Christian Boltz wrote:
Am Freitag, 24. August 2001 19:03 schrieb Dirk Hebenstreit:
[Problem: Verzeichnisse per NFS exportieren, dass nur der Besitzer Zugriff erhält, nicht aber andere Rechner/Nutzer]
Ich würde als Lösung/Workaround vorschlagen, die /home-Verzeichnisse per SAMBA freizugeben und via smbmount anzubinden, da hier wenigstens ein Passwort für den Zugriff auf den Server notwendig ist (was allerdings recht unkomfortabel sein dürfte, da ich beim Mounten/Booten des Clients ja nach dem Kennwort gefragt werde.) Mögliche Alternative (als Gedankenansatz, ungeprüft!!): Automounter oder Konqueror (oder andere grafische Tools).
Hallo Dirk, hallo Leute,
gute Idee (manchmal taugen auch Micro$oft-Protokolle etwas ;-)
Nur, das SMB kein M$-Protokoll ist (nur ein "assimiliertes - Urheber ist eher IBM).
assimiliert? Obwohl ich Win 3.11 und Win98 fast auswendig kenne - ich hoffe, ich oute mich damit nicht auf dieser Mailingliste ;-) - wusste ich nicht, dass M$ mit den Borg kooperiert. Oder ist M$ Borg??? Jedenfalls danke für den Hinweis!
Wie wäre es mit mount -t smbfs -o rw,username='benutzer',password='kennwort' //server/freigabe /mountpoint
Das sollte sich auch in /etc/fstab eintragen lassen... Allerdings kann AFAIK (ungetestet) jeder Nutzer des jeweiligen Rechners durch Eingabe von mount die mount-Optionen, also auch das SMB-Password abfragen ;-(
Als Alternative: den obigen mount-Befehl per sodo in der ~/.profile des jeweiligen Benutzers ausführen (Freigabe der kompletten mount-Zeile via "visudo" als root, Beschreibung siehe manpage). Da lernen die Azubis wenigstens was...
Jepp, das liest sich gut! Das Problem mit dem Passwort in Klarschrift beim mount-Befehl ist uns auch schon mal unangenehm aufgestoßen :-/ Deine Lösung kommt jetzt erstmal in die Archivkiste (man weiß ja nie ;-)
Eine Lösung ist mir gerade noch eingefallen, vielleicht passt die ja: Es gibt doch den Befehl smbmount (hast Du ja schon erwähnt) AFAIK wird das Passwort interaktiv abgefragt. Dies gibt Dir vermutlich die Möglichkeit, es vor der mount-Ausgabe zu verstecken: smbmount //server/freigabe /mnt/samba < ~/smbpw.txt Hoffentlich stimmt die Syntax von smbmount, ich gehe mal von mount-Syntax aus. Vielleicht kann man das Passwort ja auch als Kommandozeilenparameter angeben? - man smbmount - (keine Ahnung, lies eben mal nach...) So, wenn Du jetzt noch in der Datei ~/smbpw.txt das Sambapasswort und weitere von smbmount benötigte Eingaben einträgst, liest Dir smbmount aus der "Hand" [genauer: Datei ;-)]. Die entsprechende Datei sollte aus Sicherheitsgründen die Rechtemaske -rw------- haben (nur Benutzer, lesen, schreiben). Und jetzt wären wir wieder bei ~/.profile sudo /pfad/zu/smbmount <parameter>... Zur Einrichtung von sudo: visudo aufrufen Beispiel-Konfiguration: die folgende Zeile erlaubt z. B. ein init 0 für den User halt ohne Passworteingabe halt ALL=(ALL) NOPASSWD:/sbin/init 0 Ansonsten: man sudo, man visudo, man sudoers Auf jeden Fall die komplette Befehlszeile incl. Pfad eintragen! Ich hoffe, dass diese Lösung sicher genug ist (einzig der root des jeweiligen Rechners kann die Datei mit dem Passwort mitlesen, falls kein NFS-Export eingerichtet ist) Gruß Christian Boltz -- Linux is like a wigwam: no gates, no windows, and an apache inside.
Christian Boltz wrote: ...
Nur, das SMB kein M$-Protokoll ist (nur ein "assimiliertes - Urheber ist eher IBM).
assimiliert? Obwohl ich Win 3.11 und Win98 fast auswendig kenne - ich hoffe, ich oute mich damit nicht auf dieser Mailingliste ;-) - wusste ich nicht, dass M$ mit den Borg kooperiert. Oder ist M$ Borg??? Jedenfalls danke für den Hinweis!
*grins* Schau doch mal bei /. (http://slashdot.org) vorbei, dort gibt es bei Meldungen die M$ betreffen ein nettes Foto von (nein, nicht 7of9) Borg Gates ;-) ...
Jepp, das liest sich gut! Das Problem mit dem Passwort in Klarschrift beim mount-Befehl ist uns auch schon mal unangenehm aufgestoßen :-/ Deine Lösung kommt jetzt erstmal in die Archivkiste (man weiß ja nie ;-)
Eine Lösung ist mir gerade noch eingefallen, vielleicht passt die ja: Es gibt doch den Befehl smbmount (hast Du ja schon erwähnt) AFAIK wird das Passwort interaktiv abgefragt. Dies gibt Dir vermutlich die Möglichkeit, es vor der mount-Ausgabe zu verstecken:
smbmount //server/freigabe /mnt/samba < ~/smbpw.txt Hoffentlich stimmt die Syntax von smbmount, ich gehe mal von mount-Syntax aus.
Vielleicht kann man das Passwort ja auch als Kommandozeilenparameter angeben? - man smbmount - (keine Ahnung, lies eben mal nach...)
So, wenn Du jetzt noch in der Datei ~/smbpw.txt das Sambapasswort und weitere von smbmount benötigte Eingaben einträgst, liest Dir smbmount aus der "Hand" [genauer: Datei ;-)]. Die entsprechende Datei sollte aus Sicherheitsgründen die Rechtemaske -rw------- haben (nur Benutzer, lesen, schreiben).
Und jetzt wären wir wieder bei ~/.profile sudo /pfad/zu/smbmount <parameter>...
Zur Einrichtung von sudo: visudo aufrufen Beispiel-Konfiguration: die folgende Zeile erlaubt z. B. ein init 0 für den User halt ohne Passworteingabe halt ALL=(ALL) NOPASSWD:/sbin/init 0 Ansonsten: man sudo, man visudo, man sudoers Auf jeden Fall die komplette Befehlszeile incl. Pfad eintragen!
Ich hoffe, dass diese Lösung sicher genug ist (einzig der root des jeweiligen Rechners kann die Datei mit dem Passwort mitlesen, falls kein NFS-Export eingerichtet ist)
Na bitte, das sieht doch richtig gut aus! Schön entwickelt (und gleich auch dokumentiert!), ab damit in die Tips&Tricks-Kiste :) Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
participants (4)
-
Christian Boltz -
Dirk Hebenstreit -
Falk Sauer -
Sven Schiwek