GitBSLR icon indicating copy to clipboard operation
GitBSLR copied to clipboard

Breaks in git worktrees

Open nabijaczleweli opened this issue 5 years ago • 2 comments

Consider:

git init /tmp/owo
cd /tmp/owo
ln -s ~/src/zfs/v8.build
LD_PRELOAD=~/code/GitBSLR/gitbslr.so git add .  # works
git worktree add ../ohno
cd ../ohno
ln -s ~/src/zfs/v3.strace
LD_PRELOAD=~/code/GitBSLR/gitbslr.so git add .
# GitBSLR: unexpected access to /tmp; should only be in /tmp/owo/ or /tmp/owo/.git/. Either you're missing GITBSLR_GIT_DIR and/or GITBSLR_WORK_TREE, or you found a GitBSLR bug.
cat .git
# gitdir: /tmp/owo/.git/worktrees/tree
GITBSLR_DEBUG=1 GITBSLR_GIT_DIR=/tmp/owo/.git/worktrees/tree GITBSLR_WORK_TREE=$(rea
lpath .) LD_PRELOAD=~/code/GitBSLR/gitbslr.so git add .
# GitBSLR: Loaded
# GitBSLR: The git directory path must end with .git, it can't be /tmp/owo/.git/worktrees/tree/

After patching away this check:

GITBSLR_DEBUG=1 GITBSLR_GIT_DIR=/tmp/owo/.git/worktrees/tree GITBSLR_WORK_TREE=$(rea
lpath .) LD_PRELOAD=~/code/GitBSLR/gitbslr.so git add .
# GitBSLR: Loaded
# GitBSLR: Using work tree /tmp/owo/.git/worktrees/ (autodetected)
# GitBSLR: Using git dir /tmp/owo/.git/worktrees/tree (from env)
# GitBSLR: Using work tree /tmp/tree (from env)
# GitBSLR: __lxstat64(/tmp/owo/.git/worktrees/tree/HEAD)
# GitBSLR: __lxstat64(/tmp/owo/.git/worktrees/tree/HEAD) - untouched because .git not yet located
# GitBSLR: Using git dir /tmp/owo/.git/ (autodetected)
# GitBSLR: Using work tree /tmp/owo/ (autodetected)
# GitBSLR: __lxstat64(/tmp/owo/.git/worktrees/tree/commondir)
# GitBSLR: __lxstat64(/tmp/owo/.git/worktrees/tree/commondir) - untouched because in .git
# GitBSLR: __lxstat64(/tmp)
# GitBSLR: unexpected access to /tmp; should only be in /tmp/owo/ or /tmp/owo/.git/. Either you're missing GITBSLR_GIT_DIR and/or GITBSLR_WORK_TREE, or you found a GitBSLR bug.

Glancing at the code, it looks like some accesses are special-cased based on .git and derived from that, which is broken by the Interesting:tm: setup git worktrees yield.

nabijaczleweli avatar May 22 '20 15:05 nabijaczleweli

Oh great, fixing this one will require reevaluating GitBSLR's entire security model. It's currently fairly paranoid, blocking lots of safe behaviors, but finding a more accurate ruleset without risking any security holes is gonna take a while.

I'll see what I can do, but I can't promise anything.

Alcaro avatar May 22 '20 20:05 Alcaro

It took this long to be reported, and I have a workaround for this usecase, so, please, by all means, no rush, and thanks for GitBSLR in general!

nabijaczleweli avatar May 22 '20 20:05 nabijaczleweli