[TYPO3-german] /fileadmin und Zugriffsrechte

[Michael_OF]

Gruezi Renzo und Hallo Michael,


vielen lieben Dank für Eure Antworten!

Ich habe mir die von Euch erwähnte Extension "secure_downloads" angesehen und
vorgestern Nacht im IRC Channel #TYPO3 parallel noch als weiteren Tipp die (anscheinend ähnliche) Extension "FAL Secure
Download" bekommen.

Die Dokumentation zu beiden Extensions weisen darauf hin, dass Sie nur einen Layer über den Zugriff legen, der von TYPO3
über "File Storages" implementiert ist und per Konzeption von TYPO3 direkt durch den Webserver erfolgt.

Dazu habe ich aber direkt noch ein paar Fragen:

Die Doku über den File Abstraction Layer
(https://docs.typo3.org/typo3cms/FileAbstractionLayerReference/singlehtml/Index.html#document-Administration/Storages/Index)
weist extra darauf hin (rote Box):

"This does not magically protect your files if they are within your web root (e.g. below the fileadmin folder). They
will still be available to anyone who knows the path to the file. To implement a strict access restriction the Storage
must point to some path outside the web root or the folder it points to must contain web server restrictions to block
direct access to the files it contains (for example, in an Apache .htaccess file)."

Ich habe versucht, testweise ein paar weitere File Storages / Dateispeicher anzulegen. Angelehnt an den existierenden
Daten für fileadmin/. Hat einen Moment gedauert (nichts in der Doku dazu gefunden) bis ich verstanden habe, dass man den
physikalischen Ordner selber extern anlegen muss. Im Gegensatz zum Ordner für fileadmin/, den legt TYPO3 während der
Erstinstallation selber an.

Generell hatte ich da ein paar schräge Fehlermeldungen:

Fehlt der Ordner des Dateispeichers, ist (manchmal :-S) die Baumstruktur unter Datei/Dateiliste "kaputt", Fehlermeldung
aus dem Log: Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1314516810: Folder "/" does not exist. |
TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException thrown in file
/srv/www/typo3_src-7.6.14/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php in line 285. Requested URL:
http://localhost:10080/typo3root/typo3/index.php?route=%2Ffolder%2Ftree&token=a9a525732a980b1eee9596ac665ef9cbf1092dee

Verschwindet, wenn der Ordner existiert und betriebssystemseitig die passenden Rechte hat. Konkrete Frage: Bei mir unter
OpenSuse "gehören" alle Apache Daten dem User "wwwrun" in der Gruppe "www". Für den fileadmin/ Ordner hat TYPO3 auf
Gruppenebene das "sticky Bit" gesetzt (https://de.wikipedia.org/wiki/Sticky_Bit) - soll/muss das für alle
"Dateispeicher" Ordner so sein?

Solche schrägen "manchmal" Fehler habe ich noch öfters: Wenn ich z.B. unter Datei/Dateiliste mit der rechten Maustaste
auf das Icon einer beliebigen hochgeladenen Datei geklickt habe, kam die Meldung "uid must be positive integer, 0 given"
(Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1437656456: $uid must be positive integer, 0 given |
InvalidArgumentException thrown in file
/srv/www/typo3_src-7.6.14/typo3/sysext/backend/Classes/Form/FormDataProvider/AbstractDatabaseRecordProvider.php in line
39. Requested URL:
http://localhost:10080/typo3root/typo3/index.php?route=%2Frecord%2Fedit&token=d468e2c4f137992958358e9a0235346ff2229f83&edit%5Bsys_file_metadata%5D%5B0%5D=edit&returnUrl=%2Ftypo3root%2Ftypo3%2Findex.php%3FM%3Dfile_FilelistList%26moduleToken%3Dc49c5bf5a7a01f7b13fb1e4f42b12502d9de6983%26id%3D5%253A%252FSub1%252F
)

Als Neuling hab ich gesehen, dass eine System-Extension "advanced file metadata" existiert, aber nicht aktiviert war. Da
das "passend" klang, habe ich diese mal aktiviert, und tatsächlich, der "uid must be positive integer, 0 given"-Fehler
ist jetzt weg. Lustigerweise sogar immer noch, wenn man die Extension "advanced file metadata" wieder deaktiviert :-S
Ich bekomme dann ganz normal den "abgespeckten" "Datei-Metadaten "<DATEINAME>" auf Wurzelebene bearbeiten" Dialog.

Generelle Frage dazu: Ich halte das für einen (harmlosen) Bug. Welche ich bei allen anderen Open Source Themen wenn
möglich gerne irgendwo eintrage. Für TYPO3 finde ich jetzt aber unter TYPO3.org nicht wirklich direkt einen Hinweis, wie
das Bug Tracking organisiert ist. Gibt es irgendwo eine Bugzilla Instanz oder sowas?

Letzte Fragen, generell, zum Thema .htaccess:

Die Apache Doku (und jeder, mit dem man in #httpd chattet :-)) weist deutlichst darauf hin, dass die Verwendung von
.htaccess Dateien einen nicht unerheblichen Performance-Verlust des Webservers bedeutet, da in der Ordnerstruktur im
gesamten Baum bei Zugriffen Existenz und ggf. Inhalt dieser .htaccess Dateien geprüft werden muss. Sofern man - gilt für
mich, da alles auf eigenem VPS - "root"-Zugriff hat, könnte man auf .htaccess durch server-seitige Direktiven verzichten.

Um hier möglichst einfach upgrade-fähig zu bleiben, das default-.htaccess kann sich ja jederzeit mit neuen
TYPO3-Releases ändern, habe ich einfach den Inhalt der .htaccess Datei in die "Directory" Direktive der VHOST Definition
mit aufgenommen und ansonsten .htaccess Dateien deaktiviert:

        <Directory "/srv/www/htdocs/typo3root">
                Options +FollowSymLinks
                AllowOverride None
                Require all granted
                Include /srv/www/htdocs/typo3root/.htaccess
        </Directory>

Mache ich genauso bei allen anderen .htaccess "Kandidaten" auf meinem VPS. Also z.B. bei meiner OwnCloud Instanz auf dem
gleichen VPS.

Wie macht Ihr das, gibt es da Empfehlungen? Ich hätte an sich gerne in der Direktive auch ein "Require all denied"
stehen, dann "fliegt" mir aber fast alles um die Ohren, da z.B. nichts mehr aus fileadmin/ direkt vom Apache serviert
werden darf. Z.B. .css Dateien, Grafiken, usw.... Auch hier die allgemeine Frage: Wie macht Ihr das? "All denied" und
öffnende Sonderregeln für diverse Ordner?



Viele Grüße und schöne Weihnachts-Feiertage für alle Mitleser dieser Liste,
Michael




Am 21.12.2016 um 12:00 schrieb typo3-german-request at lists.typo3.org:
> Date: Tue, 20 Dec 2016 22:25:42 +1100
> From: Michael Schams <typo3 at 2016.schams.net>
> Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
> To: German TYPO3 Userlist <typo3-german at lists.typo3.org>
> Message-ID: <mailman.5061.1482233159.628.typo3-german at lists.typo3.org>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Dateien, die nicht fuer die Oeffentlichtkeit bestimmt sind, haben meiner
> Meinung nach generell nichts in "htdocs" (oder irgendeinem Verzeichnis
> darunter) etwas zu suchen.
>
> Sorge dafuer, dass sie *ausserhalb* abgelegt werden und (wie Renzo
> erwaehnt hat) ein Script (bzw. eine TYPO3 Extension) diese liest und
> (nach entsprechender Berechtigungspruefung) an den Client sendet.
>
> Das gilt fuer vertrauliche Dokumente ebenso wie fuer Backups, MySQL
> Dumps, Git Repositories und aehnliches.
>
>
> Cheers
> Michael


-------------------------------------------------
> 
> Message: 1
> Date: Tue, 20 Dec 2016 07:53:09 +0100
> From: Renzo Bauen <typo3 at conpassione.ch>
> Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
> To: typo3-german at lists.typo3.org
> Message-ID: <mailman.5019.1482216794.628.typo3-german at lists.typo3.org>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hallo Michael
> 
> die Dateien kann man nur sch?tzen, wenn im entsprechenden Verzeichnis
> der Zugriff gesperrt ist via .htaccess und man einen PHP-Script der die
> Rechte pr?ft f?r den Zugriff verwendet.
> All das macht z.B. die Ext secure_downloads
> 
> Beste Gr?sse, Renzo
> 


-------------------------------------------------
Originale Email:
-------------------------------------------------


TYPO3 7.6.14 / Apache 2.4.23 / OpenSuse Leap 42.2


Hallo zusammen,


ich möchte als TYPO3-Neuling eine Webseite mit geschützten Inhalten aufbauen.

Für Seiten(inhalte) an sich kein Problem, da kann TYPO3 extrem viel.

Was ich aber jetzt lernen musste ist, dass per Konzept/Default der /fileadmin Ordner unter der WebRoot,
Directory-Listings zwar unterbunden sind, aber ein Zugriff über die vollständige URL dennoch möglich ist.

Ich möchte jetzt aber auch angemeldeten Benutzern Datei-Downloads als Links anbieten, die ebenso geschützt sind wie
Seiten und keinesfalls per Kenntnis des Dateinamens abrufbar sein sollen.

Reales Beispiel wäre eine Einsatzplanung für ein Projekt mit ehrenamtlich Tätigen in Form einer PDF/LibreOffice-Datei,
welche natürlich einige private Daten enthält und daher nur geschützt nach Anmeldung herunterladbar sein darf. Im
Standard "landet" diese Datei beim Upload egal über welchen Backend-Weg ich es versuche immer in /fileadmin oder
Unterordnern wie "user_upload", alles "frei" zugänglich.


Für Tipps aus der Praxis wäre ich sehr dankbar,
viele Grüße,
Michael