-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
os: CopyFS should guard against copying into the source directory #70465
Comments
Related Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
I think this is working as intended, CopyFS won't have the ability to peek into what the given abstract filesystem is, especially if the given filesystem is wrapped. |
I understand that, so, definitly the developer has to do a check before. But this behaviour is not documentated (at least as I saw). And since it do an infinite loop and will stuck the program, it can also take down the whole server. And for me, this should not happen and it is dangerous. |
Do you want to send a patch for the documentation? |
Yes, I can. Should I just open a merge request on Github ? Otherwise, is there really no way implement something ? I was thinking, maybe copy into a temporary directory and rename it to the good place. (I tried and seems to do the job). (It's kinda dirty, I agree). I was also thinking, maybe by checking if |
You can open a pull request on GitHub, or you can use Gerrit. See https://go.dev/doc/contribute. Thanks. I don't think we want to copy to a temporary directory. That penalizes every caller for a rare mistake. I think it would be OK for if osDirFS, ok := fsys.(dirFS); ok {
// check for nesting between osDirFS and dir
} |
seems it would be quite a fragile check if someone were to use say fs.Sub |
I agree that would be fragile. I haven't been able to think of any loop detector that would be reliable without preventing valid uses. |
I would dislike [os.CopyFS] trying to be clever and sometimes not following its one-sentence documentation "CopyFS copies the file system fsys into the directory dir, creating dir if necessary.". To the list of valid uses which may imply non-halting behaviour I will add copying from an lazily-infinite [io/fs.FS]. So I would say even the implementation approach of first walking fsys in its entirety before starting to copy (which would 'detect' sub-filesystems) isn't expected behaviour. |
Go version
1.23.3
Output of
go env
in your module/workspace:Output of `go env`
What did you do?
Minimal reproductible example:
Create a folder structure like that:
What did you see happen?
After running the minimal reproductible example, (I volontarily limitated it to 200ms in a goroutine, because it happen to be an infinite loop), approximately 200 files and folder are created, because the folder loop is copied in itself in an infinite loop.
What did you expect to see?
On windows, if we try to copy a directory in itself, we have a Warning dialog and the other files/folders are still copied.
I should expect that
os.CopyFS
do the copy but ignore if it is itself. Or return an error, but it could be annoying as we don't know if the rest of the files have been copied.Reference issue of os.CopyFS: #62484
The text was updated successfully, but these errors were encountered: