cgit and global configuration

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

Christian Hesse <mail@eworm.de> writes:

I think that is as designed.

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.

On 6/11/2019 11:04 AM, Christian Hesse wrote:

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

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

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

Jeff King <peff@peff.net> on Wed, 2019/06/12 15:08:

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.

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

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