On Sat, Mar 22, 2025 at 11:02 AM Ayman Bagabas <ayman.bagabas@xxxxxxxxx> wrote: > > > On Mar 22, 2025, at 8:39 PM, Elijah Newren <newren@xxxxxxxxx> wrote: > > > > On Sat, Mar 22, 2025 at 3:02 AM Ayman Bagabas via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > >> > >> From: Ayman Bagabas <ayman.bagabas@xxxxxxxxx> > >> > >> This patch allows overriding built-in commands by placing a script > >> with the same name under git-shell-commands directory. > >> > >> This is useful for users who want to extend the built-in commands > >> without replacing the original command binary. For instance, a user > >> wanting to allow only a subset of users to run the git-receive-pack > >> can override the command with a script that checks the user and > >> calls the original command if the user is allowed. > > > > Sounds like it'd open a window to generating numerous security > > vulnerabilities, break git's own commands that exec another git > > subprocess (e.g. git-stash), make debugging git bug reports harder, > > and likely break programs that use plumbing commands. > > How so? The security implications are the same as any script > defined under git-shell-commands. Git does not handle authentication > nor authorization and it shouldn't do so, and this can allow repository > based authorization to happen using git-shell. > > Forgive my limited knowledge about git internals but how would this > break git's own commands that exec another git subprocess and > plumbing commands? Sorry, I wasn't reading closely enough and missed the part where this was specific to `git shell` as opposed to a general ability to override built-ins.