On Mon, May 9, 2022 at 9:01 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > But I was totally wrong ;-) No matter what a unprivileged attacker > does with these knobs, the actual access will be done by a process > run by the attacker, and the actual security at the filesystem level > still kicks in to prevent the attacker from doing anything that the > attacker cannot normally do. While I agree with you in principle, wouldn't this approach (while far more flexible) also be more risky? Let's imagine a scenario where we enhance SUDO_UID (because it actually makes sense to do so now since it's probably better to run hooks as a non privileged user by default instead of root). At that point all an attacker needs to do to escalate to root is to set its own SUDO_UID=0 and whatever else we put in the production binary for him to use. At least by restricting this overriding functionality to a real root user (as done in the proposal) we could make that attack vector less likely. After all, I am sure that when (I know it is not fair, because it is not the only way to do so) core.fsmonitor was invented as a useful way to run things in a repository, nobody expected it could be weaponized later into a privilege escalation, and feels like doing the same here might show we have not learned that lesson. Eitherway RFC v4 is out and waiting for feedback, and I even have an enhanced (with even more comments and hopefully even better commit messages) in which every single message has gone through a free grammar checker[1] which I am planning to publish as v4 proper sometime this week. Carlo [1] https://www.gingersoftware.com/grammarcheck
