git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* cgit and global configuration
@ 2019-06-11 15:04 Christian Hesse
  2019-06-11 19:55 ` Junio C Hamano
  2019-06-11 20:22 ` Jeff Hostetler
  0 siblings, 2 replies; 4+ messages in thread
From: Christian Hesse @ 2019-06-11 15:04 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List, Jeff Hostetler, Jason A. Donenfeld

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cgit and global configuration
  2019-06-11 15:04 cgit and global configuration Christian Hesse
@ 2019-06-11 19:55 ` Junio C Hamano
  2019-06-11 20:22 ` Jeff Hostetler
  1 sibling, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2019-06-11 19:55 UTC (permalink / raw)
  To: Christian Hesse; +Cc: Git Mailing List, Jeff Hostetler, Jason A. Donenfeld

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cgit and global configuration
  2019-06-11 15:04 cgit and global configuration Christian Hesse
  2019-06-11 19:55 ` Junio C Hamano
@ 2019-06-11 20:22 ` Jeff Hostetler
  2019-06-12 19:08   ` Jeff King
  1 sibling, 1 reply; 4+ messages in thread
From: Jeff Hostetler @ 2019-06-11 20:22 UTC (permalink / raw)
  To: Christian Hesse, Junio C Hamano
  Cc: Git Mailing List, Jeff Hostetler, Jason A. Donenfeld



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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cgit and global configuration
  2019-06-11 20:22 ` Jeff Hostetler
@ 2019-06-12 19:08   ` Jeff King
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff King @ 2019-06-12 19:08 UTC (permalink / raw)
  To: Jeff Hostetler
  Cc: Christian Hesse, Junio C Hamano, Git Mailing List,
	Jeff Hostetler, Jason A. Donenfeld

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-11 15:04 cgit and global configuration Christian Hesse
2019-06-11 19:55 ` Junio C Hamano
2019-06-11 20:22 ` Jeff Hostetler
2019-06-12 19:08   ` Jeff King

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox