Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#65,248 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu tại apps/dav/lib/Connector/Sabre/Directory.php, khoảng dòng 571 trong getNodeForPath(), và theo dõi cách xử lý kết quả getFileInfo() của các thư mục tổ tiên; báo cáo cho biết phương thức có thể trả về false trước hàm khởi tạo Directory. Kiểm tra các bài kiểm thử liên quan đến đường dẫn này và bổ sung kiểm thử cho một thư mục tổ tiên không thể đọc được. Hoàn tất khi yêu cầu không còn gây ra TypeError/HTTP 500 và hành vi khớp với phản hồi dự kiến là không tìm thấy hoặc cấp quyền truy cập.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
PHP
Star
37k
Fork
5.3k
Merge trung bình
1 ngày 23 giờ
Pull request đã merge (30 ngày)
751

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nextcloud/server

Tất cả issue của nextcloud/server

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.