--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-22T17:57:49Z"
+ content="""
+So I did, fixed now.
+"""]]
+++ /dev/null
-I was git-annex-adding a folder of big files.
-I ran the command while inside a folder I didn't need anymore.
-I deleted the folder with nautilus (moved it to trash) which caused the cwd to change and that really confused git-annex.
-
-Root of repo is audio-recordings/
-
-While inside audio-recordings/a I ran `git annex add ../audio-files`
-
-Then I deleted audio-recordings/a with Nautilus which caused its path to change to /.Trash-1000/files/a
-
-As soon as git-annex finished hashing the file it was hashing, this happened:
-
-```
-add ../audio-files/moto-maxx/2018.04.17 1438.wav
-100% 579.95 MiB 160 MiB/s 0s
- ../audio-files/moto-maxx/2018.04.17 1438.wav changed while it was being added
-failed
-fatal: not a git repository: '../.git'
-error: unknown option `cached'
-usage: git diff --no-index [<options>] <path> <path>
-...
-[the entire help message]
-...
---find-object <object-id>
- look for differences that change the number of occurrences of the specified object
- --diff-filter [(A|C|D|M|R|T|U|X|B)...[*]]
- select files by diff type
- --output <file> Output to a specific file
-
-(recording state in git...)
-fatal: not a git repository: '../.git'
-^Ceral-pathspecs","add","--"] exited 123)
-
-```
-
-The file that was being added was left like this:
-
-```
-ll "audio-files/moto-maxx/2018.04.17 1438.wav"
-
--r--r--r-- 2 ### ### 608121644 abr 17 2018 'audio-files/moto-maxx/2018.04.17 1438.wav'
-```
-
-It appears git-annex just chmoded it, but didn't symlinkify it.
-
-### What version of git-annex are you using? On what operating system?
-
-`Ubuntu 20.04 focal`
-
-`Linux 5.8.0-050800-generic`
-
-`git-annex version: 8.20200226`
-
-### 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)
-
-I am absolutely in love with it. I even built a special remote for it and I'm now building another because that one was stupid.
-
-Seriously, git-annex is amazing.
-
-***
-
-## edit:
-
-Turns out this "bug" affects pretty much everything.
-
-TL;DR: relative path access will be made relative to the new location if you move a directory that's got something running in it, so don't.
-
- [[done]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2020-08-06T18:01:23Z"
- content="""
-Thanks, I was able to reproduce this easily:
-
- git init r
- cd r
- mkdir a
- mkdir b
- dd if=/dev/zero of=a/big bs=1M count=1000
- cd b
- git annex add ../a & (sleep 1; mv ../b ~/trash)
-
-By moving the directory the process is running in, all relative path
-accesses it does after the move are relative to the new location. This is
-super unsafe, but I don't know if it's super unsafe in a way that's unique to
-git-annex. If a process does any relative path accesses with ../ in them,
-it's going to be vulnerable to being flung around in this way and will start
-to do unexpected things.
-
-git seems to avoid this being a problem by starting with a chdir to the top
-of the repo, and then uses relative paths without ../. (Mostly.. --git-dir
-with ../ in it will make git use such paths.)
-
-Other commands.. not so much. `rm -rf ../foo` ends by unlinking "../foo"
-so if it's flung around it will delete the wrong thing. (Though its
-directory tree traversal uses openat() and so avoids deleting a whole wrong
-directory tree.) And `vim ../foo` overwrote an existing file after being
-moved, bypassing its usual protections about overwriting a modified file.
-
-So, I think the super unsafe thing is generally moving directories around
-when they have processes running in them. Unfortunately, the file manager
-has a good reason to want to do it to handle deletions too.. Well, my
-opinion of unix's safety was already not great, but it's now gone down some
-more.
-
-(Fun thing to consider: What if you have the ability to move a directory
-that a root-owned process is running in, and the root-owned process does
-relative paths accesses? This seems like it could be a fertile source of
-security holes.)
-
-----
-
-The git error message about the cached option happen when "git diff
---cached" is run outside a git repository. Why is it outside a git
-repository? See above. So I don't think it can be avoided.
-
-Only improvement that seems feasible is, to keep an open handle to the
-file, so it can fchmod the fix the permissions back.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="cardoso-neto"
- avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
- subject="Understood."
- date="2020-08-07T02:24:43Z"
- content="""
-Thank you for the detailed and timely response.
-
-That was some good thinking there with this being a possible attack vector. Food for thought right there.
-
-Btw, I'm sorry for explaining what I did instead of providing you with commands to reproduce the bug. I don't know what I was thinking. Git-annex has been a very big part of my life these last few years and I got a little nervous while writing the bug report. lol
-
-I shall be more careful with from where I run my commands henceforth.
-"""]]
--- /dev/null
+I was git-annex-adding a folder of big files.
+I ran the command while inside a folder I didn't need anymore.
+I deleted the folder with nautilus (moved it to trash) which caused the cwd to change and that really confused git-annex.
+
+Root of repo is audio-recordings/
+
+While inside audio-recordings/a I ran `git annex add ../audio-files`
+
+Then I deleted audio-recordings/a with Nautilus which caused its path to change to /.Trash-1000/files/a
+
+As soon as git-annex finished hashing the file it was hashing, this happened:
+
+```
+add ../audio-files/moto-maxx/2018.04.17 1438.wav
+100% 579.95 MiB 160 MiB/s 0s
+ ../audio-files/moto-maxx/2018.04.17 1438.wav changed while it was being added
+failed
+fatal: not a git repository: '../.git'
+error: unknown option `cached'
+usage: git diff --no-index [<options>] <path> <path>
+...
+[the entire help message]
+...
+--find-object <object-id>
+ look for differences that change the number of occurrences of the specified object
+ --diff-filter [(A|C|D|M|R|T|U|X|B)...[*]]
+ select files by diff type
+ --output <file> Output to a specific file
+
+(recording state in git...)
+fatal: not a git repository: '../.git'
+^Ceral-pathspecs","add","--"] exited 123)
+
+```
+
+The file that was being added was left like this:
+
+```
+ll "audio-files/moto-maxx/2018.04.17 1438.wav"
+
+-r--r--r-- 2 ### ### 608121644 abr 17 2018 'audio-files/moto-maxx/2018.04.17 1438.wav'
+```
+
+It appears git-annex just chmoded it, but didn't symlinkify it.
+
+### What version of git-annex are you using? On what operating system?
+
+`Ubuntu 20.04 focal`
+
+`Linux 5.8.0-050800-generic`
+
+`git-annex version: 8.20200226`
+
+### 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)
+
+I am absolutely in love with it. I even built a special remote for it and I'm now building another because that one was stupid.
+
+Seriously, git-annex is amazing.
+
+***
+
+## edit:
+
+Turns out this "bug" affects pretty much everything.
+
+TL;DR: relative path access will be made relative to the new location if you move a directory that's got something running in it, so don't.
+
+ [[done]]
--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-06T18:01:23Z"
+ content="""
+Thanks, I was able to reproduce this easily:
+
+ git init r
+ cd r
+ mkdir a
+ mkdir b
+ dd if=/dev/zero of=a/big bs=1M count=1000
+ cd b
+ git annex add ../a & (sleep 1; mv ../b ~/trash)
+
+By moving the directory the process is running in, all relative path
+accesses it does after the move are relative to the new location. This is
+super unsafe, but I don't know if it's super unsafe in a way that's unique to
+git-annex. If a process does any relative path accesses with ../ in them,
+it's going to be vulnerable to being flung around in this way and will start
+to do unexpected things.
+
+git seems to avoid this being a problem by starting with a chdir to the top
+of the repo, and then uses relative paths without ../. (Mostly.. --git-dir
+with ../ in it will make git use such paths.)
+
+Other commands.. not so much. `rm -rf ../foo` ends by unlinking "../foo"
+so if it's flung around it will delete the wrong thing. (Though its
+directory tree traversal uses openat() and so avoids deleting a whole wrong
+directory tree.) And `vim ../foo` overwrote an existing file after being
+moved, bypassing its usual protections about overwriting a modified file.
+
+So, I think the super unsafe thing is generally moving directories around
+when they have processes running in them. Unfortunately, the file manager
+has a good reason to want to do it to handle deletions too.. Well, my
+opinion of unix's safety was already not great, but it's now gone down some
+more.
+
+(Fun thing to consider: What if you have the ability to move a directory
+that a root-owned process is running in, and the root-owned process does
+relative paths accesses? This seems like it could be a fertile source of
+security holes.)
+
+----
+
+The git error message about the cached option happen when "git diff
+--cached" is run outside a git repository. Why is it outside a git
+repository? See above. So I don't think it can be avoided.
+
+Only improvement that seems feasible is, to keep an open handle to the
+file, so it can fchmod the fix the permissions back.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Understood."
+ date="2020-08-07T02:24:43Z"
+ content="""
+Thank you for the detailed and timely response.
+
+That was some good thinking there with this being a possible attack vector. Food for thought right there.
+
+Btw, I'm sorry for explaining what I did instead of providing you with commands to reproduce the bug. I don't know what I was thinking. Git-annex has been a very big part of my life these last few years and I got a little nervous while writing the bug report. lol
+
+I shall be more careful with from where I run my commands henceforth.
+"""]]
projects / git-annex.git / commitdiff