-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
path/filepath: EvalSymlinks, incorrect traversal of relative paths #30520
Comments
Can you provide a reproducer that does not depend on a specific OS and working directory? I've read this issue three times and I still don't understand what exactly is wrong with the current logic. |
If I'm reading this correctly, the case in question is when someone uses |
@ianlancetaylor, That's what I thought too (though it should still work in that case), but here it's using the correct number of Here's a self-contained repro for linux: Dockerfile
eval_symlinks.go
|
I think this is a self-contained example that doesn't require Docker or assumptions about home directory layout. package main
import (
"fmt"
"io/ioutil"
"log"
"os"
"path/filepath"
"strings"
)
func main() {
tmpdir, err := ioutil.TempDir("", "EvalSymlinks")
if err != nil {
log.Fatal(err)
}
if err := os.Chdir(tmpdir); err != nil {
log.Fatal(err)
}
defer os.RemoveAll(".")
if err := os.Mkdir("a", 0777); err != nil {
log.Fatal(err)
}
if err := os.Symlink("a", "b"); err != nil {
log.Fatal(err)
}
if err := ioutil.WriteFile(filepath.Join("a", "file"), nil, 0666); err != nil {
log.Fatal(err)
}
wd, err := os.Getwd()
if err != nil {
log.Fatal(err)
}
up := strings.Repeat(".." + string(os.PathSeparator), strings.Count(wd, string(os.PathSeparator)))
up = filepath.Join("..", up, wd, "b", "file")
if eval, err := filepath.EvalSymlinks(up); err != nil {
fmt.Fprintf(os.Stderr, "EvalSymlinks(%q) failed: %v\n", up, err)
} else {
fmt.Println(eval)
}
up = filepath.Join("..", up)
if eval, err := filepath.EvalSymlinks(up); err != nil {
fmt.Fprintf(os.Stderr, "EvalSymlinks(%q) failed: %v\n", up, err)
} else {
fmt.Println(eval)
}
} |
When I run that program I see
In other words, evaluating the path fails by itself, and succeeds when adding a |
Change https://golang.org/cl/164762 mentions this issue: |
@ianlancetaylor I don't think it's an extra I modified your example to follow the patten above, which still fails with
outputs:
|
Do you think you could add to the test in https://golang.org/cl/164762 to show the problem? |
Sorry, here's the above example formatted as a test. If someone wants to remind me how to push a single commit to an existing changeset in gerrit, I can give it another try, but it's been a long time since I've used gerrit.
|
Thanks. I added a similar test case, and a fix for the problem. |
Change https://golang.org/cl/165197 mentions this issue: |
@gopherbot please open backport to 1.12. |
Backport issue(s) opened: #30586 (for 1.12). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
EvalSymlinks was mishandling cases like "/x/../../y" or "../../../x" where there is an extra ".." that goes past the start of the path. Updates #30520 Fixes #30586 Change-Id: I07525575f83009032fa1a99aa270c8d42007d276 Reviewed-on: https://go-review.googlesource.com/c/go/+/164762 Reviewed-by: Bryan C. Mills <[email protected]> (cherry picked from commit 294edb2) Reviewed-on: https://go-review.googlesource.com/c/go/+/165197 Reviewed-by: Brad Fitzpatrick <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
Relative paths with
../
and symlinks are not correctly evaluated.This reproduces the issue on macOS, since the
$TMPDIR
in/var
is a symlink by default, starting from the path$HOME/foo
Which outputs
The resolution seems to depend on the number of
../
in the path, as it does work from$HOME
with../../var/folder
. The errors strings also alternate the number of reported../
depending on whether there were an odd or even number in the original path.The behavior is the same on linux on linux with a similar directory structure.
The text was updated successfully, but these errors were encountered: