nfs - user und Rechte (yavdr 0.3)

Also über yaVDR speziell kann ich nichts sagen, allerdings über NFS.

Zitat

Original von vanTuxen
- kann man noch einen User mitgeben, mit dem verbunden werden soll?
- mit welchem User wird verbunden (vdr, root, install user)

NFS verwendet keinen Usernamen oder Passwort um mit dem Server zu verbinden. Es wird einfach nur eine Verbindung hergestellt. In seiner einfachsten Form müssen bei NFS die Clients vertrauenswürdig sein, denn es wird einfach die UserID verwendet, mit der der Benutzer gerade auf dem Client eingeloggt ist. Das kann auch root sein, wenn in der /etc/exports "no_root_squash" angegeben wurde.

Damit aber der Benutzer wirklich die gleichen Rechte hat wie auf dem Client, müssen die Gruppen übereinstimmen. Ist also z.B. ein User auf dem Client in der Gruppe "users", auf dem Server aber nicht, dann hat er serverseitig nicht das Recht auf Dateien zuzugreifen die der Gruppe "users" vorbehalten sind.

Zitat

- als nobdoy bzw. nogroup wird verbunden, da die UserId auf yavdr seite nicht mit der UserId auf Server Seite übereinstimmt, oder?

Nein, es wird mit der client-seitigen Benutzerid verbunden. Nur wenn root-squashing aktiviert ist und die UserId 0 zugreift, wird in der Regel das ganze auf nobody:nogroup gemappt.

Zitat

2. Server:
- Das Verzeichnis /srv/nfs/audio erstellt und dieses zum Test dem User nobody und group nogroup zugeweisen.

Dann muss aber auch der client in der Gruppe "nogroup" sein, es sei denn du greifst als root zu.

Zitat

da die eigentlichen Files auf mehrere exteren Platten verteilt ist, liegen im Verzeichnis Sym-Links.

Das funktioniert nicht, weil NFS auf Inode-Basis arbeitet. Du musst jede Festplatte einzeln per NFS freigeben.

Zitat

- muss ich an den Rechten auf die freigegebenen Verzeichnisse noch was ändern.

Du solltest dir eine Rechtestruktur ausdenken, die du dann auf beiden Rechnern anlegst. Dabei müssen überall die gleichen Gruppen existieren und auch alle User in den selben Gruppen sein. Am besten du verwendest nur Benutzer-IDs die größer als 1000 sind. Alles unter 1000 ist für das System reserviert.

Zitat

- kann man die UserId und GroupIds einfach in der passwd und group so abändern, dass sie dem yavdr entprechen? (z.B. hat mysql auf dem server die id, die der vdr user auf dem yavdr hat)

Nein, auf keinen Fall. Also prinzipiell geht das schon, dann müsstest du aber nach dem ändern der Benutzer-ID alle Rechte neu setzen. Besser ist, du fasst Benutzer-IDs unter 1000 einfach nicht an.

Zitat

Original von vanTuxen
Für die Sym-Links hab ich schon was schönes gefunden:Using symbolic links with NFS

Das ist nur eines der Probleme die bei symbolischen Links auftreten können. Das eigentliche Problem ist, dass NFS nicht über mount-points hinweg zugreifen kann. Wenn sich das mittlerweile nicht geändert hat, dann sieht der Client deine externen Festplatten nicht. Er sieht zwar die Links aber kann nicht drauf zugreifen, weil das ein anderer Mount-Point ist. Alle mount points müssen (oder mussten) einzeln freigegeben werden.

Zitat

Bei yavdr wird anscheinend mit dem user root verbunden. Nachdem ich no_root_squash eingestellt habe funktionierts auch.

Sehr unsauber von yaVDR gelöst. VDR muss eigentlich nicht als root laufen.

Zitat

Original von Temar
Sehr unsauber von yaVDR gelöst. VDR muss eigentlich nicht als root laufen.

Tut er auch nicht, hat seinen eigenen eingeschränkten account.

Zitat

Sehr unsauber von yaVDR gelöst. VDR muss eigentlich nicht als root laufen.

Selbstverständlich läuft der VDR in yaVDR nicht als root

Und was versucht dann mit dem root account auf sein NFS zuzugreifen?

Nicht VDR

root      1566     1  0 Nov04 ?        00:00:00 /usr/sbin/automount -t 0

autofs/automount

Zitat

Original von steffen_b
autofs/automount

Ich bin jetzt mit autofs/automount nicht mehr vertraut, aber ist es nicht so, dass automount das NFS Verzeichnis nur mountet?

Ich hab automount zuletzt vor 8 Jahren benutzt, daher bin ich nicht auf dem aktuellen Stand, aber damals wurde nur die Mount-Operation ausgeführt. Die einzelnen Zugriffe wurden weiterhin unter der entsprechenden Benutzer-ID durchgeführt. Und so sollte es ja eigentlich auch sein, denn sonst würde das Rechte-Management kompromittiert.

Hat sich das wohl geändert? Wenn ja, wisst ihr zufällig warum? Das macht doch die komplette Rechterverteilung zu nichte.

Ich weiss nicht wovon du sprichst Temar. Natürlich hängt der nur ein. Die Rechte sind so wie sie sind bei der Freigabe.

Mountoptionen sind: rw,nosuid,nodev,hard,intr,sloppy,addr=

Zitat

Original von steffen_b
Ich weiss nicht wovon du sprichst Temar.

Ich beziehe mich auf vanTuxen's Problem von weiter oben. Bei ihm wurden Zugriffe von yaVDR auf das NFS per root durchgeführt. Andernfalls hätte er nicht "no_root_squash" angeben müssen.

Kann natürlich sein, dass er irgendwelche eigenen Modifikationen vorgenommen hat. Ich fand deine Antwort nur merkwürdig, weil autofs/automount ja nichts mit den eigentlichen Zugriffen zu tun hat. Insofern spielt die UserID von automount aus Sicht des NFS Servers keine Rolle. Den NFS Server interessiert nur die Benutzer-ID des Users, der auf die Daten zugreifen will - und das war bei vanTuxen eben root. Darauf bezog ich mich.

no root squash brauch man wenn die freigabe auf dem server root gehört hat nichts mir dem client zu tun IMHO

Zitat

Original von steffen_b
no root squash brauch man wenn die freigabe auf dem server root gehört hat nichts mir dem client zu tun IMHO

Das ist nicht richtig. Bei der einfachsten Form von NFS, wenn man also kein Kerberos oder ähnliche Authentifizierungsmethoden verwendet, geht es nur um die Benutzer-ID des Clients. Root Squashing verhindert einfach nur, dass der root User des Clients Vollzugriff bekommt. "no_root_squash" muss also immer dann angegeben werden, wenn man vom Client aus per root auf das NFS share zugreifen will. Ansonsten wird der root-Account automatisch auf nobody:nogroup gemappt (oder was man eben auf dem Server eingestellt hat).

Siehe auch: man 5 exports

Zitat

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash.

Haben denke ich mal aneinander vorbeigeredet, bzw ich habe nicht gründlich genug gelesen. Ich hab das Geschriebene grade nochmal überflogen.

Freigaben die auf dem Server dem user root gehören, gehören standardmässig dann nobody. (siehe ersten Post). Was genau mit "wird verbunden" gemeint ist weiss ich nicht. Wenn versucht wird auf dem Server auf Aufnahmen oder Medien zuzugreifen (via vdr-sxfe oder XBMC) dann wird das auch mit no_root_sqash nicht funktionieren, da alle Prozesse wie vdr, vdr-sxfe und xbmc als system-user vdr ausgeführt werden. Dieser User hat ein paar zusätzliche Rechte auf DBus um per Hal mounten zu können (USB Mount) oder Dienste zu starten und zu stoppen (per upstart).

Mein Gedanke war, das der Eingentümer root auf dem Server für irgendwas worauf er am yavdr-client zugreifen will, nicht gerade ideal ist.

Zitat

Sehr unsauber von yaVDR gelöst. VDR muss eigentlich nicht als root laufen.

Stimmt, würden wir auch nicht tun. Aber das ist ja inzwischen geklärt.

Zitat

Original von steffen_b
Freigaben die auf dem Server dem user root gehören, gehören standardmässig dann nobody.

Nein, Freigaben die auf dem Server root gehören, gehören auch weiterhin root. Nur der root User des Clients hat keine Rechte mehr darauf zuzugreifen, weil er serverseitig auf nobody:nogroup gemappt wird.

Zitat

Stimmt, würden wir auch nicht tun. Aber das ist ja inzwischen geklärt.

Dann hat vanTuxen wohl irgendwas modifiziert.