Warum darf "user" in eine root-Datei schreiben, aber "root" nicht in eine user-Datei?

[buhtz]

Scheinbar habe ich nach all den Jahren etwas Elementares noch nicht verstanden.

Vereinfacht formuliert würde ich sagen, diese Datei gehört "root":

Code: Alles auswählen

$ ls -l /tmp/foo.bar
-rw-rw-rw- 1 root root 0  5. Apr 14:44 /tmp/foo.bar

Als "user" kann ich da reinschreiben, weil "others" (also das "rw-" am rechten Ende) die "rw" Rechte hat.

Code: Alles auswählen

$ echo "user here" >> /tmp/foo.bar

Machen wir es mal anders herum. Die Datei gehört "user":

Code: Alles auswählen

-rw-rw-rw- 1 user user 10  5. Apr 14:46 /tmp/foo.bar

Code: Alles auswählen

# echo "root was here" >> /tmp/foo.bar
bash: /tmp/foo.bar: Keine Berechtigung

Ist "root" etwa nicht "others"?

[heisenberg]

Es ist wohl ein neuerer Schutzmechanismus des Linux-Kernels:

https://docs.kernel.org/admin-guide/sys ... ed-regular

[niemand]

Obacht: /tmp ist ein tmpfs, und da gelten andere Regeln. In einem „normalen“ Dateisystem darf Root natürlich auch weiterhin in Userfiles rumschreiben. Unabhängig von den Dateirechten, btw.

[buhtz]

Ah, OK.

Ähm... Wie solve ich das jetzt? Der Hintergrund ist, dass ich in /tmp eine flock Datei ablege. Die betreffende Anwendung (backintime-qt bzw. backintime) kann als "user" und als "root" (via polkit) starten (manuell, via cron, via udev).

Damit die vielen möglichen Instanzen sich nicht in die Quere kommen, setzen sie ein exklusives flock auf die Datei und warten ggf. bis der flock der anderen Instanz freigegeben ist.

Um ehrlich zu sein, habe ich flock noch nicht voll und ganz verstanden. Und der betreffende Code kommt von einem Entwickler, auf den ich keinen Zugriff mehr habe.

Original Upstream Code
Vereinfach sieht der betreffende Code so aus, wobei mich das "open(..., 'w')" irritiert.

Code: Alles auswählen

self.flock = open(self.GLOBAL_FLOCK, 'w')
fcntl.flock(self.flock, fcntl.LOCK_EX)  # blocks (waits) until an existing flock is released
# make it rw by all if that's not already done.
perms = stat.S_IRUSR | stat.S_IWUSR | stat.S_IRGRP |stat.S_IWGRP | stat.S_IROTH | stat.S_IWOTH
s = os.fstat(self.flock.fileno())
if not s.st_mode & perms == perms:
    os.fchmod(self.flock.fileno(), perms)

Verstehen tue ich nicht, warum man für ein flock die Datei überhaupt öffnen muss. Der Aufruf von "fcntl.flock()" funktioniert aber nur mit einem File-Handle und nicht mit einem Dateinamen.

Und ich frage mich, ob es den unbedingt ein schreibender Zugriff sein muss. Die Anwendung schreibt da nix rein, keine PID oder ähnliches. Abgesehen von den Internas der Anwendung, die ihr natürlich nicht kennen müsst, frage ich mich, ob es vom unixoiden flock Konzept her notwendig ist hier mit Schreibrechten zu öffnen.

In einem kurzen Test mit zwei Python REPL schien es nämlich auch mit einem einfachen Lesezugriff zu funktionieren. So würde ich dann auch diese Permission Probleme umgehen.

Nun ja, die Anwendung ist alt und hat mutmaßlich eine sehr große Userbasis. Kleineste Änderungen können große Auswirkung haben, weshalb ich hier so genau nachfrage. In Issue haben wir dafür natürlich auch.

[niemand]

Ähm... Wie solve ich das jetzt?

Ich woulde die Datei simply in ein normales Dateisystem putten, etwa unter /var/tmp oder so similar.

[heisenberg]

Das Verhalten tritt wohl nur in Verbindung mit tmpfs auf.

Mögliche Lösungen:

a) Nutzung eines Ablageverzeichnisses, an der kein tmpfs bei dem kein Sticky-Bit gesetzt ist (/var/lock/deineapp/, /var/tmp/deineapp/ oder /tmp/deineapp/)

b) Setze einen

Code: Alles auswählen

chown $(id -nu):$(id -ng) lockfile 

auf die Lockdatei vor dem flock (Als user darf das gerne fehlschlagen (Ausgabeumlenkung!)).

[Livingston]

Nochmal zur Ursachenforschung:
Liegt es nicht einfach am Stick-Bit, mit dem /tmp normalerweise gemountet wird?

Code: Alles auswählen

drwxrwxrwt   7 root root   200  8. Apr 12:36 tmp/
         ^

[heisenberg]

Liegt es nicht einfach am Stick-Bit, mit dem /tmp normalerweise gemountet wird?

Sehr wahrscheinlich. Das mit dem tmpfs war bzgl. der Ursache vermutlich falsch.

[niemand]

Das mit dem tmpfs war bzgl. der Ursache vermutlich falsch.

Grad zur Sicherheit probiert: in einem ext4-Dateisystem ein Verzeichnis erstellt, das Root gegeben, 777 und Sticky-Bit gesetzt → Root kann problemlos in Userdateien schreiben. Ich denke also schon, dass es mit dem tmpfs zu tun hat.

Edit, Nachtrag: wenn ich allerdings einen Mountpoint eines ext4-Dateisystems mit 1777 versehe, funktioniert’s wieder nicht.

Nachtrag2: entsprechend funktioniert’s in einem Unterverzeichnis unterhalb von /tmp wieder sehr wohl: als User ein Verzeichnis in /tmp/ erstellt und leere Datei angelegt → Root kann reinschreiben. Entsprechend könnte buhtz ein Unterdirectory in /tmp createn, und dort sein Lockfile reinputten.

[Livingston]

Entsprechend könnte buhtz ein Unterdirectory in /tmp createn, und dort sein Lockfile reinputten.

Indeed, das seems tatsächlich correctly zu worken.

[buhtz]

Danke für die Hinweise.

wie ist den eure Meinung zu Schreib- oder Lesezugriff. Ist meine Beobachtung und Annahme korrekt, dass ein lesender Zugriff (also "open(handle, 'r')") ausreichend wäre?

In dem Fall müsste ich den Ort der Datei gar nicht ändern, den Lesen darf jeder.

EDIT: Anstatt /var/lock wird heutzutage scheinbar /run/lock empfohlen. Ersteres ist in Debian 13 nur ein symlink auf Letzteres.

[heisenberg]

wie ist den eure Meinung zu Schreib- oder Lesezugriff. Ist meine Beobachtung und Annahme korrekt, dass ein lesender Zugriff (also "open(handle, 'r')") ausreichend wäre?

IMHO brauchst weder Schreib- noch Lesezugriff auf die Datei. Du brauchst aber ein Write-Lock. Denn nur damit ist die Garantie der einmaligen Ausführung gegeben, weil es nur ein Write-Lock auf einer Datei zur gleichen Zeit geben darf. Read-Locks dagegen darf es viele gleichzeitig geben. Ansonsten würde ich vermuten, dass Python verlangt, dass Du eine Datei auch zum Schreiben öffnen musst, wenn Du ein Write-Lock darauf setzen möchtest.