2016-04-07 25 views
0

Ich habe zwei verkettete FUSE-Dateisysteme, die zusammenarbeiten sollen, beide laufen als root: Prozess P versucht auf Datei zuzugreifen F zuerst durch FS1; FS1 schaut nach FS2. Jetzt muss FS2 die Kontextinformationen (pid, user und group) von P (und nicht von FS1) abrufen, um zu überprüfen, ob P die Berechtigung zum Zugriff auf die Dateien hat.FUSE: wie man den ursprünglichen (Nicht-root) Benutzer des aufrufenden Prozesses beim Verketten von FUSE-basierten Dateisystemen erhält

Was ist der empfohlene Weg, dies zu tun?

+0

Wenn sie beide als root ausgeführt wird, keiner weiß, wer P ist. Was ist der Zweck, in User Space zu laufen, wenn Sie als root laufen wollen? Wenn Sie ssh-Zugriff haben und FS2 wissen soll, wer Sie sind, melden Sie sich direkt an. Wenn Sie nur FS2 über FS1 erreichen können, verwenden Sie ssh zum Tunneln. – LinuxDisciple

+0

Meine Frage bezieht sich auf FUSE-Dateisysteme im Allgemeinen und nicht auf sshfs (impliziert durch Details in Ihrem Kommentar.) –

+0

Ich sehe jetzt, dass ich sshfs falsch abgeleitet habe. – LinuxDisciple

Antwort

0

Diese Frage wird effektiv beantwortet: Change UID/GID only of one thread in Linux

Dateisystem-Operationen (offen, stat, etc.) aus FS1, die Dateien von FS2 müssen im Besitz zugreifen, wenn der Benutzer des anrufenden Prozesses durchgeführt, um werden, um sicherzustellen Diese Dateisystemberechtigungen werden respektiert. Die kanonische Methode hierfür besteht darin, die Thread-spezifischen APIs setfsuid und setfsgid zu verwenden, damit FS1 bei der Ausführung als Root die Dateisystemoperationen so ausführt, als würde es als Nicht-Root-Benutzer ausgeführt. Bei einem Fehlschlag des fs-Aufrufs sollte errno sofort erfasst werden. Danach sollten setfsuid und setfsgid verwendet werden, um die effektive uid/gid zurück auf root/root zu setzen.

Siehe fs_unlink Beispiel hier: https://sourceforge.net/p/fuse/mailman/message/29362682/