Re: a problem with git describe

From: Carlo Arenas <carenas@gmail.com>
Date: Apr 26, 2022, 16:35 UTC
Message-ID: <CAPUEspiufPMZOfZFunTFYmX7KwPxsKsAeHnfBjKgosA1ZJWqzw@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.2204261742120.355@tvgsbejvaqbjf.bet>

On Tue, Apr 26, 2022 at 8:43 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

>
> Maybe a better idea for the `sudo` scenario would be to make use of
> `SUDO_UID` (assuming that no adversary can gain control over the user's
> environment variables)?

I like this idea, and will prepare a formal patch soon also including DOAS_UID for anyone that might have used that instead of sudo to elevate their privileges.

Still think that (since we are already touching this) removing the restriction to root owned directories might make sense though, ex the following (unrealistic example) would work:

  $ mkdir -p r/t
  $ sudo chown root r
  $ cd r && sudo git init
  $ cd t && git status

IMHO any directories above that are owned by root and might have a git configuration must be safe, and therefore shouldn't need to be explicitly exempted.

I also think that Taylor's suggestion to ignore and warn instead of abort might be a better solution to the "configuration file shouldn't be trusted" issue which is at the root of this regression, and obviously doing that would make this change less critical (users will just get a warning instead of being prevented to do what worked for them before and is a safe use case)

Carlo

PS. yes hardcoding uid 0 as root would be avoided, not sure where yet though