Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: WebDAV TypeError (HTTP 500) in Directory::getNodeForPath when an ancestor is hidden by a Team folders ACL (Directory.php:571)

Aperta Adatta ai principianti
  • Qualcosa non va?
#65,248 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
php
Ambito
api, backend

Direzione di ricerca

Inizia in apps/dav/lib/Connector/Sabre/Directory.php, intorno alla riga 571 di getNodeForPath(), e segui come vengono gestiti i risultati di getFileInfo() degli antenati; il rapporto dice che può restituire false prima del costruttore di Directory. Controlla i test correlati a questo percorso e aggiungi una copertura per un antenato non leggibile. Il lavoro è terminato quando la richiesta non produce più un TypeError/HTTP 500 e il comportamento corrisponde alla risposta prevista di non trovato o accesso concesso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

34-feedback
Bug description

A WebDAV request for a folder whose parent is not readable to the user returns HTTP 500 (TypeError) instead of a clean response, when the parent is hidden by a Team folders (groupfolders) ACL rule.

OCA\DAV\Connector\Sabre\Directory::getNodeForPath() walks up the ancestors to check that each one is readable (added in #54441, "to keep ACL checks working in files_accesscontrol"):

// apps/dav/lib/Connector/Sabre/Directory.php, v34.0.4, lines 569-571
$info = $this->fileView->getFileInfo($scanPath, false);
$directory = new Directory($this->fileView, $info, $this->tree, $this->shareManager);
$readable = $directory->getNode()->isReadable();

For an ancestor that a groupfolders ACL makes unreadable, View::getFileInfo() returns false, not an unreadable FileInfo. The false reaches the Directory constructor unchecked, which throws:

TypeError: OCA\DAV\Connector\Sabre\Directory::__construct(): Argument #2 ($info) must be of type OCP\Files\FileInfo,
false given, called in /var/www/html/apps/dav/lib/Connector/Sabre/Directory.php on line 571
  #00 OCA\DAV\Connector\Sabre\Directory->__construct()      apps/dav/lib/Connector/Sabre/Directory.php:571
  #01 OCA\DAV\Connector\Sabre\Directory->getNodeForPath()   3rdparty/sabre/dav/lib/DAV/Tree.php:86
  #02 Sabre\DAV\Tree->getNodeForPath()                      3rdparty/sabre/dav/lib/DAV/Server.php:971
  #03 Sabre\DAV\Server->getPropertiesIteratorForPath()      3rdparty/sabre/dav/lib/DAV/Server.php:1664
  #04 Sabre\DAV\Server->writeMultiStatus()                  3rdparty/sabre/dav/lib/DAV/Server.php:1649
  #05 Sabre\DAV\Server->generateMultiStatus()               3rdparty/sabre/dav/lib/DAV/CorePlugin.php:346
  #06 Sabre\DAV\CorePlugin->httpPropFind()                  3rdparty/sabre/event/lib/WildcardEmitterTrait.php:89
  #07 Sabre\DAV\Server->emit()                              3rdparty/sabre/dav/lib/DAV/Server.php:472
  #08 Sabre\DAV\Server->invokeMethod()                      apps/dav/lib/Connector/Sabre/Server.php:215
  #09 OCA\DAV\Connector\Sabre\Server->start()               apps/dav/lib/Server.php:434
  #10 OCA\DAV\Server->exec()                                apps/dav/appinfo/v2/remote.php:25
  #11 require_once()                                        remote.php:152

Uploads fail the same way. A PUT into the folder reaches the same line through OCA\DAV\Upload\ChunkingV2Plugin->beforePut() → prepareUpload() (ChunkingV2Plugin.php:171 / 342) → Tree->getNodeForPath().

This also blocks the legitimate case

This isn't only a configuration that is "unsupported by design":

  1. The ACL engine grants the access. occ groupfolders:permissions <id> --test --user alice Restricted/alice reports +read, +write, +create, +delete, +share, and the web UI / ACL model let admins configure exactly this. Users with a valid grant get a server error instead of either their data or a clean denial. Desktop clients see a 500, not a 403/404, so they can't tell "no access" from "server broken".
  2. The same unguarded call has another trigger with no ACL involved. Groupfolders trashbin entries over WebDAV hit it too: nextcloud/groupfolders#4984 (same TypeError, same getNodeForPath chain, NC 33.0.7 / groupfolders 21.0.13, open). Any path where getFileInfo() returns false for an ancestor turns into a 500.

Whatever the intended outcome is (207 because the ACL grants read, or 404 because the parent is unreadable, as the loop's NotFound suggests), a TypeError/500 shouldn't be the answer. A minimal fix would treat $info === false like an unreadable ancestor and throw NotFound.

Steps to reproduce
  1. Nextcloud 34.0.4 with Team folders 22.0.6 (groupfolders/acl-inherit-per-user at its default false; true behaves the same).
  2. Create a team folder TF. Grant group dept (members alice, bob) all permissions. Enable advanced permissions.
  3. Create the subfolders TF/Restricted and TF/Restricted/alice.
  4. occ groupfolders:permissions <id> --group dept Restricted -- -read
  5. occ groupfolders:permissions <id> --user alice Restricted/alice -- +read +write +create +delete
  6. occ groupfolders:permissions <id> --test --user alice Restricted/alice → +read, +write, +create, +delete, +share
  7. As alice: PROPFIND /remote.php/dav/files/alice/TF/Restricted/alice with Depth: 0 (or 1) → HTTP 500, <s:exception>TypeError</s:exception>.
  8. As alice: PUT /remote.php/dav/files/alice/TF/Restricted/alice/test.txt → HTTP 500.

Variants tested, each in both acl-inherit-per-user modes:

Rule for dept on Restricted alice → Restricted/alice
-read 500
-read -write 500
-read -write -create -delete -share 500
+read -write -create -delete -share (parent readable), sibling folders denied 207 (works)

Users who can read Restricted (e.g. a group with +read on it) get 207 on Restricted/alice. Only users for whom an ancestor is unreadable hit the TypeError.

Expected behavior

No 500. Either the ACL-granted access (207), or, if readable ancestors are intentionally required, a 404 Not Found like the rest of getNodeForPath() produces.

Nextcloud Server version

34 (observed on 34.0.4)

Affected versions
  • Observed: 34.0.4 (official image nextcloud:34.0.4-apache).
  • By source inspection: the same unguarded getFileInfo() → new Directory() lines exist since #54441 in 33.0.0 and later, stable33, stable34 (identical to 34.0.4), 35.0.0, 35.0.1 and master. stable32 does not have this code path. There is no 34.0.5 yet.
Operating system / PHP / Web server / Database

Official Docker image nextcloud:34.0.4-apache: Debian, PHP 8.5.10 (mod_php), Apache 2.4.68, behind a reverse proxy. PostgreSQL 18.6.

List of activated apps (relevant)

groupfolders 22.0.6, admin_audit 1.24.0, files_versions, files_trashbin, files_sharing (defaults of the image otherwise).

Additional info

Related: nextcloud/groupfolders#4984 (same TypeError, trashbin trigger). Introduced with nextcloud/server#54441 ("Add INodeByPath to Directory").

Lingua principale
PHP
Stelle
37k
Fork
5.3k
Merge medio
2g 1h
PR unite (30g)
723

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextcloud/server

Tutte le issue di nextcloud/server

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.