File Browser: Trailing-slash directory deletion leaves public shares active for recreated paths

Summary

File Browser v2.63.15 can leave a public directory share behind when the shared directory is deleted through a path with a trailing slash. The share cleanup path calls DeleteWithPathPrefix(file.Path, userID), but the Bolt backend performs the database prefix query with the unnormalized argument before trimming the slash for boundary checks. For a stored share at /a, deleting /a/ queries for paths prefixed by /a/, so the exact /a share is never loaded and never deleted.

If a directory with the same path is later recreated, the stale public share becomes active again and exposes the new directory contents through the old public URL.

Impact

An authenticated user with share, download, and delete permissions can create a valid public share, delete the shared path with a trailing slash, and leave the public link in storage. The link is dormant while the path does not exist, but it exposes future content if the same path is recreated later. The final data exposure is unauthenticated through the public share URL.

This bypasses the intended lifecycle cleanup around public shares and is adjacent to the recent public-share path-existence and prefix-boundary fixes.

Reproduction

The following test was run against v2.63.15, commit be23ab3a15bf957928ecfed88de5ab67850c1b9c.

1. Create a scoped user with share, download, and delete permissions.
2. Create /a/old.txt in that user's scope.
3. Store a valid public share row with Hash: "h", UserID: 1, and Path: "/a".
4. Send an authenticated delete request for /a/ through the resource delete handler.
5. Confirm the directory is deleted.
6. Confirm share hash h still exists in storage.
7. Recreate /a/future.txt.
8. Request the public share handler at h/ and observe that the unauthenticated response includes future.txt.

Command used for the local proof:

go test ./http -run TestValidationTrailingSlashDeleteLeavesExactDirectoryShare -count=1 -v

Observed result:

=== RUN   TestValidationTrailingSlashDeleteLeavesExactDirectoryShare
--- PASS: TestValidationTrailingSlashDeleteLeavesExactDirectoryShare (0.03s)
PASS
ok  github.com/filebrowser/filebrowser/v2/http  0.044s

Root cause

storage/bolt/share.go queries the share index before normalizing the path:

func (s shareBackend) DeleteWithPathPrefix(pathPrefix string, userID uint) error {
    var links []share.Link
    if err := s.db.Prefix("Path", pathPrefix, &links); err != nil {
        ...
    }

    prefix := strings.TrimRight(pathPrefix, "/")

    for _, link := range links {
        if link.UserID != userID {
            continue
        }

        if link.Path != prefix && !strings.HasPrefix(link.Path, prefix+"/") {
            continue
        }
        ...
    }
}

For pathPrefix == "/a/", the database prefix query can return descendants such as /a/child, but it does not return the exact share path /a. The later TrimRight cannot delete the exact share because that row was not loaded from storage.

http/resource.go passes the request-derived path into this cleanup before removing the resource:

file, err := files.NewFileInfo(... Path: r.URL.Path ...)
...
err = d.store.Share.DeleteWithPathPrefix(file.Path, d.user.ID)
...
return d.user.Fs.RemoveAll(r.URL.Path)

A request for /a/ therefore removes the directory but misses the exact /a share row.

Remediation

Normalize the path before querying the share index, and cover both the exact normalized path and its descendants. Add regression tests where a stored share path /a is removed by DeleteWithPathPrefix("/a/", userID) and where DELETE /api/resources/a/ deletes the exact public share row.

Fixed in version 2.63.17.