Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#65,248 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
api, backend

Línea de trabajo

Empieza en apps/dav/lib/Connector/Sabre/Directory.php, alrededor de la línea 571 de getNodeForPath(), y sigue cómo se gestionan los resultados de getFileInfo() de los directorios antecesores; el informe indica que puede devolver false antes del constructor de Directory. Revisa las pruebas relacionadas con esta ruta y añade cobertura para un antecesor ilegible. El trabajo estará terminado cuando la solicitud ya no produzca un TypeError/HTTP 500 y el comportamiento coincida con la respuesta prevista de no encontrado o acceso concedido.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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").

Lenguaje dominante
PHP
Estrellas
37k
Forks
5.3k
Merge medio
2 d 1 h
PR fusionados (30 d)
723

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/server

Todos los issues de nextcloud/server

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.