You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by "paultanay (via GitHub)" <gi...@apache.org> on 2026/05/11 18:46:36 UTC

[I] [Bug] [skywalking]

paultanay opened a new issue, #13871:
URL: https://github.com/apache/skywalking/issues/13871

   ### Search before asking
   
   - [x] I had searched in the [issues](https://github.com/apache/skywalking/issues?q=is%3Aissue) and found no similar issues.
   
   
   ### Apache SkyWalking Component
   
   BanyanDB (apache/skywalking-banyandb)
   
   ### What happened
   
   `banyand/backup/restore.go` builds local restore paths from object names returned by the remote filesystem. The code does not verify that the final cleaned path stays under `rootPath/<catalog>/data`.
   
   Affected path:
   
   - `restoreByName` lists remote files with `fs.List`.
   - It derives `relPath` from the remote object name.
   - It builds `localPath` with `filepath.Join(rootPath, catalogName, storage.DataDir, relPath)`.
   
   If a backup source contains an object name with parent-directory segments under the expected backup prefix, restore can create a file outside the intended catalog data directory.
   
   There is a related issue in `pkg/fs/remote/local/local.go`: the local `file://` remote filesystem adapter joins caller-supplied paths directly with `baseDir` in `Upload`, `Download`, `List`, and `Delete`. Those operations also need a containment check after path cleaning.
   
   I verified both behaviors locally with focused Go tests.
   
   ### What you expected to happen
   
   Restore should reject any remote object path that escapes the expected backup prefix or resolves outside the target catalog data directory.
   
   The local `file://` remote filesystem adapter should also reject paths that resolve outside its configured base directory.
   
   ### How to reproduce
   
   Minimal restore test setup:
   
   1. Configure or mock a backup source that returns an object name under the expected backup prefix but containing parent-directory traversal segments.
   2. Run `restoreByName`.
   3. Check the filesystem. The restored file is written outside `rootPath/<catalog>/data`.
   
   For the local remote filesystem adapter:
   
   1. Create a local remote filesystem with a temporary base directory.
   2. Call `Upload` with a path containing parent-directory traversal segments.
   3. The file is created outside the configured base directory.
   
   ### Anything else
   
   Suggested fix:
   
   - Reject absolute paths.
   - Reject cleaned paths that are `..` or start with `../`.
   - In the local filesystem adapter, compare the cleaned absolute target path against the cleaned absolute base directory before reading, writing, listing, or deleting.
   - In restore, validate every object returned by `fs.List` before deriving the local path.
   - Add regression tests for restore and the local `file://` remote filesystem adapter.
   
   ### Are you willing to submit a pull request to fix on your own?
   
   - [x] Yes I am willing to submit a pull request on my own!
   
   ### Code of Conduct
   
   - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [Bug] [BanyanDB] Backup restore can write outside the target data directory [skywalking]

Posted by "hanahmily (via GitHub)" <gi...@apache.org>.
hanahmily closed issue #13871: [Bug] [BanyanDB] Backup restore can write outside the target data directory
URL: https://github.com/apache/skywalking/issues/13871


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org