HTTP 403 beim Herunterladen von Dokumenten

[The-Compiler]

Ev. ähnlich zu #23 - https://studentenportal.ch/dokumente/ad1/2213/ gibt einen HTTP 403 ("Verkürzter Foliensatz" auf https://studentenportal.ch/dokumente/ad1/)

[The-Compiler]

Das error-log von nginx sagt:

2020/08/25 19:09:12 [error] 10#10: *316996 open() "/srv/www/studentenportal/media/documents//ad1/2020-08-25_20-24-21.pdf" failed (13: Permission denied), client: 217.182.175.162, server: studentenportal.ch, request: "HEAD /dokumente/ad1/2213/ HTTP/2.0", upstream: "http://172.18.0.2:8000/dokumente/ad1/2213/", host: "studentenportal.ch"

Seltsamerweise sind die Dateiberechtigungen ziemlich unterschiedlich gesetzt:

root@d8cbe55bee9b:/var/log/nginx# ls -l /srv/www/studentenportal/media/documents//ad1   
total 76308
-rwxrwxr-x 1 1001 1001 6236641 Jul 23  2014 2014-07-23_23-30-34.zip
-rwxrwxr-x 1 1001 1001 1854067 Sep 21  2015 2015-09-21_22-06-34.pdf
[...]
-rw-r--r-- 1 1001 1001  314950 Aug 25 18:22 2020-08-25_20-22-55.pdf
[...]
-rw------- 1 1001 1001 3516051 Aug 25 18:24 2020-08-25_20-24-21.pdf

Da scheint also noch irgendwas schiefzulaufen bei den Berechtigungen. Ich könnte das von Hand korrigieren, aber die Frage ist wohl, warum die Berechtigungen überhaupt so kaputt (und unterschiedlich!) sind.

[fabianhauser]

Ist das evtl. noch ein Relikt der Migration?

Edit: Ah nein, das sind ja neue Uploads...

[smokja]

Hab mehrer Dateien versucht hochzuladen um zu sehen, ob dies für alle Dateien gilt. Anscheinend passiert dies nur bei Dateien die ich mit dem PDFXchange bearbeitet habe. Z.B Page extraction in diesem Beispiel. Habe das gleiche Problem jetzt für Automaten und Sprachen, da habe ich auch ein PDF hochgeladen, das mit PDFXchange bearbeitet wurde.

Vielleicht hilft das weiter

[The-Compiler]

Django hat eine FILE_UPLOAD_PERMISSIONS-Setting. Mit Django 2.2 ist diese standardmässig auf None:

If this isn’t given or is None, you’ll get operating-system dependent behavior. On most platforms, temporary files will have a mode of 0o600, and files saved from memory will be saved using the system’s standard umask.

@fabianhauser @dbrgn Habt ihr ne Ahnung, wie das auf dem alten Server gelöst war? War dort irgendwo noch eine spezielle umask gesetzt? (siehe unten - vermutlich war das Verhalten von Django damals einfach noch anders...)

Mit der Standard-umask von 002 würde ich also eigentlich erwarten, dass neu hochgeladene Dokumente die Berechtigungen als 644 (und nicht 600) haben. Wenn ich mir die Files oben anschaue, ist das aber teilweise 644, teilweise 600 bei neuen Dateien.

Ich war erstmal ziemlich baff, aber hab jetzt glaubs herausgefunden, wieso:

In den Django 3.0 release notes heisst es:

In older versions, the FILE_UPLOAD_PERMISSIONS setting defaults to None. With the default FILE_UPLOAD_HANDLERS, this results in uploaded files having different permissions depending on their size and which upload handler is used.

FILE_UPLOAD_PERMISSIONS now defaults to 0o644 to avoid this inconsistency.

Das scheint in der Tat von der Dateigrösse abzuhängen! Siehe die Upload-Dokumentation:

Together MemoryFileUploadHandler and TemporaryFileUploadHandler provide Django’s default file upload behavior of reading small files into memory and large ones onto disk.

Erklärt dann wohl auch, warum es nur mit PDFXchange-PDFs passiert, das bläht wohl die Dateigrösse auf :smile:

Long story short: Wir wollen vermutlich einfach FILE_UPLOAD_PERMISSIONS = 0o644 setzen und die Berechtigungen für bestehende Files korrigieren. Bin mir grad nicht sicher, wie ich das am besten lokal teste (und hab grad nicht wirklich viel Zeugs aufgesetzt), aber kann gerne einfach mal "blind" einen PR aufmachen und hoffen, es hilft.