On April 27, 2022 5:00 PM, Carlo Arenas wrote: >On Wed, Apr 27, 2022 at 11:54 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> The "sudo sh to get a shell, chdir to /var/tmp/foo to do something" >> use case does care---it needs to make sure that whereever it goes is >> not part of a hostile repository. So "if SUDO_UID is there, anything >> goes" is not a good protection for such a use case. > >FWIW that was never part of the proposal, indeed making git aware of SUDO_ID >when it is running as only as root was part of the design to avoid other users >probably allowing repositories they don't control by having an evil SUDO_ID. > >as per the root user, I was expecting that he could be trusted more and that >wouldn't accidentally get an evil SUDO_ID on their session because it is something >that gets generated from their original account and they should be aware of it and >even might need to tweak it >(ex: by un setting it if it gets in the way). <snip> For perspective, the root user is specifically only trusted so far my community. Mucking about with repositories is frowned upon except for special system configuration repositories (ones for /etc, ssl certs, for example, and they have to sign those). Commit signing is being deployed to detect and as much practical prevent root (or any other user, elevated or not) from inappropriate repo history operations. Just sharing a different POV. --Randall
