This commit is contained in:
Joey Hess 2022-05-03 12:26:29 -04:00
parent 43701759a3
commit 961d05a90e
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 27 additions and 0 deletions

View file

@ -25,3 +25,5 @@ Linux ctchpcpx163.merck.com 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:1
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
That I use it enough to run into corner-case issues shows its continued usefulness :) That I use it enough to run into corner-case issues shows its continued usefulness :)
[[!meta title="git-annex import follows symlinks"]]

View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-05-03T16:15:38Z"
content="""
`git-annex import $dir` also follows symlinks inside $dir.
So importing has been behaving this way since long before the directory
special remote supported importtree.
This is not a security hole, because if an attacker wants to make you
import `/foo` when importing `/bar`, and they have write access to bar,
they are not limited to making a `/bar/foo -> /foo` symlink. They can just
`cp -a /foo /bar` instead.
I don't really think it would make much sense for any import to import
symlinks as symlinks. If the symlink points outside the imported directory,
that would result in a symlink that points outside the git repository,
which is not something one often wants to check into a git repository.
I don't know if I would really consider this a bug either. It at least
seems plausible that there might be users who import from `~/disk`
which is a symlink to `/media/somethinglong`, and rely on it following
the symlink. I often make symlink aliases for mount points like that,
though I have not imported from them.
"""]]