From: Joey Hess Date: Thu, 22 Oct 2020 17:57:56 +0000 (-0400) Subject: rename to avoid windows stupididy about legal filenames X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~106^2~56 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=577af1b6799e9cf0a7bd528dca4aa58674bbed3c;p=git-annex.git rename to avoid windows stupididy about legal filenames --- diff --git a/doc/bugs/Error_cloning_repository_on_Windows/comment_3_2e291373a2f3cd3e90e2c0bbad2cda7d._comment b/doc/bugs/Error_cloning_repository_on_Windows/comment_3_2e291373a2f3cd3e90e2c0bbad2cda7d._comment new file mode 100644 index 0000000000..dd5a2ab767 --- /dev/null +++ b/doc/bugs/Error_cloning_repository_on_Windows/comment_3_2e291373a2f3cd3e90e2c0bbad2cda7d._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2020-10-22T17:57:49Z" + content=""" +So I did, fixed now. +"""]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files..mdwn b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files..mdwn deleted file mode 100644 index c1fe61532d..0000000000 --- a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files..mdwn +++ /dev/null @@ -1,68 +0,0 @@ -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 [] -... -[the entire help message] -... ---find-object - 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 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]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_1_04201aa4345db10dbb5fb4637946d9c1._comment b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_1_04201aa4345db10dbb5fb4637946d9c1._comment deleted file mode 100644 index 29954e8dad..0000000000 --- a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_1_04201aa4345db10dbb5fb4637946d9c1._comment +++ /dev/null @@ -1,52 +0,0 @@ -[[!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. -"""]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_2_18501567083a4cdb1beaab401b9e7d4f._comment b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_2_18501567083a4cdb1beaab401b9e7d4f._comment deleted file mode 100644 index 7d1f185e92..0000000000 --- a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files./comment_2_18501567083a4cdb1beaab401b9e7d4f._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!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. -"""]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files.mdwn b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files.mdwn new file mode 100644 index 0000000000..c1fe61532d --- /dev/null +++ b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files.mdwn @@ -0,0 +1,68 @@ +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 [] +... +[the entire help message] +... +--find-object + 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 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]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_1_04201aa4345db10dbb5fb4637946d9c1._comment b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_1_04201aa4345db10dbb5fb4637946d9c1._comment new file mode 100644 index 0000000000..29954e8dad --- /dev/null +++ b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_1_04201aa4345db10dbb5fb4637946d9c1._comment @@ -0,0 +1,52 @@ +[[!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. +"""]] diff --git a/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_2_18501567083a4cdb1beaab401b9e7d4f._comment b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_2_18501567083a4cdb1beaab401b9e7d4f._comment new file mode 100644 index 0000000000..7d1f185e92 --- /dev/null +++ b/doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files/comment_2_18501567083a4cdb1beaab401b9e7d4f._comment @@ -0,0 +1,14 @@ +[[!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. +"""]]