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.