Re: [PATCH v2 3/3] t: add tests for safe.directory when running with sudo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 28, 2022 at 1:32 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> On a box I happen to be using, the grep gives me
>
>     Defaults secure_path=/usr/sbin:/usr/bin:/sbin:/bin
>
> and makes the prereq fail.  Which is sort-of expected, and I
> understand why this check is here, but I suspect that any sane and
> sensible installations would reinitialize the path to a fairly
> restricted one with the mechanism, so we wouldn't be testing this on
> majority of places, I am afraid.

our CI runs with macOS should still work, and any place that does is
better that none IMHO

> What we really care is that we use the same PATH as the test
> environment uses, including "we want to test the binary we just
> built" (or "at the specified path", when GIT_TEST_INSTALLED is in
> effect).  I wonder what the right way to carry $PATH and other
> environment variables down to whatever "sudo" in the test runs.

sadly the issue is even more insidious because the PATH is not
changed, but sudo ignores it when going to look for a binary to run

>     $ foo=foobla; export foo
>     $ sudo sh -c set | grep foo; echo $?
>     1
>
> so resetting PATH from an environment we export, e.g.
>
>     USE_THIS_PATH=$PATH sudo sh -c '
>         PATH=$USE_THIS_PATH
>         ... invoke our git normally here  ...
>         git status
>     '
>
> would not work X-<.  Worse yet, other environment variables such as
> GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME that we set in our tests may
> probably be cleared before "sudo" runs any test command, so rejecting
> an installaion whose "sudo" resets PATH with the above check is probably
> insufficient to give our tests a reasonable envionment to run in.

I think we are confusing, running the whole suite with sudo vs running
a specific command inside a test with it.  We obviously will need to
adapt our suite a lot more before it will natively support sudo and
that might never happen as well, since there are conflicting
objectives there.  IMHO that doesn't mean we shouldn't try.

Maybe I should document better what I meant with "awkward", but yes I
was serious when I said "minimal support" for running things through
sudo, but I should mention the ones you provided almost worked AS-IS
so it is not that bad IMHO.

Carlo



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux