Changed from fs.stat(p) to fs.unixFS.Lstat(p) - #141
Conversation
to fix deletion of symlinks
WalkthroughThe Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
server/filesystem/filesystem.go (1)
404-407: Consider documenting symlink behavior.The function comment doesn't mention how symbolic links are handled. After these changes, symlinks are treated as files and deleted directly without following them. Consider adding a note about this behavior to help users understand that symlinks won't be dereferenced during deletion.
Example addition:
// SafeDeleteRecursively deletes a file or directory while respecting the denylist. // For files, deletion is skipped if the file matches the denylist. For directories, // it recursively deletes all non-denylisted files and subdirectories. Empty directories // are removed automatically, but directories containing denylisted files are preserved. +// Symbolic links are treated as files and deleted without following them.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
server/filesystem/filesystem.go(2 hunks)
🔇 Additional comments (2)
server/filesystem/filesystem.go (2)
409-409: Correct fix for symlink handling.Changing from
StattoLstatis the right approach here. This prevents following symbolic links, which was causing "openat2: bad path resolution" errors when symlinks pointed outside the filesystem root. WithLstat, symlinks are now treated as files and deleted directly without dereferencing them, which is the correct behavior for a deletion operation and maintains security boundaries.
439-439: Consistent with the initial path check.The change to
Lstathere maintains consistency with line 409. This ensures that the existence check after recursive deletion doesn't attempt to follow symlinks, which would cause the same openat2 errors that the initial check was experiencing.
SafeDeleteRecursively was failing with "openat2: bad path resolution" errors when encountering symlinks that point outside the filesystem root.
Changes :
fs.Statwithfs.unixFS.Lstatin both the initial file info retrieval and the directory existence check, which allows for correct processing of symbolic links and special files during recursive deletion.I have tested this and it fixes the issue and doesnt seem to cause any side effects
This fixes the path resolution errors while maintaining the security boundaries that openat2 enforces.
Let me know if you see any issues with this!
Summary by CodeRabbit