cgit and global configuration

cgit and global configuration

[Christian Hesse]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Dear Jeff, dear Junio,

for cgit we use the static git library built into the executable. This used
to work well, but breaks with latest release v2.22.0: Our code unsets HOME
and XDG_CONFIG_HOME to mitigate loading arbitrary configuration.
We have tests that use strace to check for access to directories given by
environment variables.

With the new trace2 code in place at least tracing configuration is loaded
before cmd_main() kicks in. This happens in trace2_initialize_fl() ->
tr2_sysenv_load() -> read_very_early_config(). The offending commit is
bce9db6d ("trace2: use system/global config for default trace2 settings") [0].

I had thought about adding a new option to struct config_options and making
xdg_config_home() and expand_user_path() conditional in
do_git_config_sequence() when called from read_very_early_config(). However
this breaks the test suite as ptrace2 tests with global configuration depend
on HOME being set to a trash directory. Any hint about how to properly solve
this?
Or can we be sure configuration read at this point can not do any harm and
updating out tests is sufficient? I guess no as file paths can be specified.

[0] https://github.com/git/git/commit/bce9db6de97c95882a7c46836bb6cc90acf0fef0
-- 
Best regards,
Christian Hesse

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: cgit and global configuration

[Junio C Hamano]

Christian Hesse <mail@eworm.de> writes:

> With the new trace2 code in place at least tracing configuration is loaded
> before cmd_main() kicks in. This happens in trace2_initialize_fl() ->
> tr2_sysenv_load() -> read_very_early_config().

I think that is as designed.

> The offending commit is
> bce9db6d ("trace2: use system/global config for default trace2 settings") [0].

So it does not help very much to stop at calling it "offending",
without explaining what problem exactly you are trying to complain
about, and why you do not want your code traceable from the
configuration.

Re: cgit and global configuration

[Jeff Hostetler]

On 6/11/2019 11:04 AM, Christian Hesse wrote:
> Dear Jeff, dear Junio,
> 
> for cgit we use the static git library built into the executable. This used
> to work well, but breaks with latest release v2.22.0: Our code unsets HOME
> and XDG_CONFIG_HOME to mitigate loading arbitrary configuration.
> We have tests that use strace to check for access to directories given by
> environment variables.
> 
> With the new trace2 code in place at least tracing configuration is loaded
> before cmd_main() kicks in. This happens in trace2_initialize_fl() ->
> tr2_sysenv_load() -> read_very_early_config(). The offending commit is
> bce9db6d ("trace2: use system/global config for default trace2 settings") [0].
> 
> I had thought about adding a new option to struct config_options and making
> xdg_config_home() and expand_user_path() conditional in
> do_git_config_sequence() when called from read_very_early_config(). However
> this breaks the test suite as ptrace2 tests with global configuration depend
> on HOME being set to a trash directory. Any hint about how to properly solve
> this?
> Or can we be sure configuration read at this point can not do any harm and
> updating out tests is sufficient? I guess no as file paths can be specified.
> 
> [0] https://github.com/git/git/commit/bce9db6de97c95882a7c46836bb6cc90acf0fef0
> 

I'm not sure I fully understand the problem here, so let me
ask a few questions.

If you're using the static git library (by that I assume you
mean libgit.a) and the call to trace2_initialize_fl() is in
main() in common-main.c, how it is getting called?  Don't you
have your own main()?

     Looking at your source in `https://git.zx2c4.com/cgit/tree/cgit.c`
     it looks like you're defining a cmd_main() and using the rest of
     Git's Makefile, so I'm guessing you're getting common-main.c too.

I'm curious why a call to read_very_early_config() before cmd_main()
causes problems.

     Again, in `https://git.zx2c4.com/cgit/tree/cgit.c` I found
     the code in prepare_repo_env() where you unset the various
     HOME variables.  And that is called during your cmd_main()
     sequence.  That would explain why my read_very_early_config()
     causes you problems that a call to read_early_config() inside
     your cmd_main() does not.

     I'm not sure I understand the reasons for the unsets and the
     need for the strace guards, but that is not my business, so
     I'll just trust that you have your reasons.  And I have to
     assume that you have security concerns that supersede the
     need to do any tracing or advanced logging.

Adding a new bit to `struct config_options` doesn't really help
because you don't know when (or even have an opportunity) to set
it.  You've abdicated main() to common code and so your application
doesn't start until cmd_main() is called.

     And you can't really have an environment or config variable
     to say to ignore mine, because they'd be just as vulnerable.

     I'm not sure what you meant by a `ptrace2` test -- unless
     that is just a typo and that you meant the t/t021*.sh tests.
     And yes, these tests do test the global config setting.

As for going forward, I see 3 options:

[1] update your tests to allow this.  (I didn't dig thru your
     tests to see how extensive this might be.)

[2] define your own version of common-main.c and link with it
     instead of git/common-main.c and delete the calls to trace2_*()
     in it.

[3] define your own version of common-main.c and then call your
     prepare_repo_env() prior to trace2_initialize().

Granted, I've only spent 15 minutes looking at your code, so
I may be mistaken about several things, but I think those are
your options.

Hope this helps,
Jeff

Re: cgit and global configuration

[Jeff King]

On Tue, Jun 11, 2019 at 04:22:32PM -0400, Jeff Hostetler wrote:

> As for going forward, I see 3 options:
> 
> [1] update your tests to allow this.  (I didn't dig thru your
>     tests to see how extensive this might be.)
> 
> [2] define your own version of common-main.c and link with it
>     instead of git/common-main.c and delete the calls to trace2_*()
>     in it.
> 
> [3] define your own version of common-main.c and then call your
>     prepare_repo_env() prior to trace2_initialize().
> 
> Granted, I've only spent 15 minutes looking at your code, so
> I may be mistaken about several things, but I think those are
> your options.

After reading the original report, my instinct was that (2) or (3) is
probably the right way forward. We could make it a little easier for
them by splitting up common-main a bit into two parts:

  - put the actual setup bits into a callable run_cmd_main() that ends
    up in libgit.a

  - make common-main.c a tiny shim that does:

      int main(int argc, const char **argv)
      {
		return run_cmd_main(argc, argv);
      }

And that makes it easy for them to replace just that shim with some
setup steps, ending in calling run_cmd_main().

All that said, it sounds like cgit doesn't actually need to do any setup
that _must_ be in-process; it's just modifying state like environment
variables that is passed down to children.

So I think it would also be sufficient to simply wrap it with something
like:

  #!/bin/sh
  unset HOME
  unset XDG_CONFIG_HOME
  exec /path/to/cgit "$@"

But maybe there are reasons not to want the complexity of a wrapper.

-Peff

Re: cgit and global configuration

[Christian Hesse]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Jeff King <peff@peff.net> on Wed, 2019/06/12 15:08:
> On Tue, Jun 11, 2019 at 04:22:32PM -0400, Jeff Hostetler wrote:
> 
> > As for going forward, I see 3 options:
> > 
> > [1] update your tests to allow this.  (I didn't dig thru your
> >     tests to see how extensive this might be.)
> > 
> > [2] define your own version of common-main.c and link with it
> >     instead of git/common-main.c and delete the calls to trace2_*()
> >     in it.
> > 
> > [3] define your own version of common-main.c and then call your
> >     prepare_repo_env() prior to trace2_initialize().
> > 
> > Granted, I've only spent 15 minutes looking at your code, so
> > I may be mistaken about several things, but I think those are
> > your options.  
> 
> After reading the original report, my instinct was that (2) or (3) is
> probably the right way forward. We could make it a little easier for
> them by splitting up common-main a bit into two parts:
> [...]

We decided to go another way and introduced a constructor function which does
initial environment setup:

https://git.zx2c4.com/cgit/commit/?id=034e3c7d56ba71ce281886fe8525b16d4559fac1

Everything (including tests) is happy with that.
-- 
Best regards,
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: cgit and global configuration

[Jeff King]

On Fri, Oct 25, 2019 at 06:10:15PM +0200, Christian Hesse wrote:

> We decided to go another way and introduced a constructor function which does
> initial environment setup:
> 
> https://git.zx2c4.com/cgit/commit/?id=034e3c7d56ba71ce281886fe8525b16d4559fac1
> 
> Everything (including tests) is happy with that.

Thanks for following up. I think that should be a fine solution. We'd
perhaps have considered using __attribute__((constructor)) ourselves
(which would presumably have a non-deterministic run order), but it's
not sufficiently portable for our purposes. So I don't think you'll run
into any issues going forward with that approach.

-Peff