Git --file doesn't override $HOME in version 1.8.1.2

Git --file doesn't override $HOME in version 1.8.1.2

[Sarajärvi Tony]

Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.

In Puppet we launch Git with the command: '/usr/bin/git config --file /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration System"'
However, puppet logs: "fatal: unable to access '/root/.config/git/config': Permission denied".

Puppet is run as root, so HOME points to /root, but still -file should override the environment variable.

If the same command is run directly from terminal as root, it works as well.

With 1.8.3.2 the problem didn't reoccur.

-Tony
-------
Digia, Qt

Re: Git --file doesn't override $HOME in version 1.8.1.2

[Thomas Rast]

Sarajärvi Tony <Tony.Sarajarvi@digia.com> writes:

> Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
>
> In Puppet we launch Git with the command: '/usr/bin/git config --file
> /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration
> System"'
> However, puppet logs: "fatal: unable to access '/root/.config/git/config': Permission denied".
>
> Puppet is run as root, so HOME points to /root, but still -file should override the environment variable.
>
> If the same command is run directly from terminal as root, it works as well.

To elaborate (I briefly talked to Sarajärvi on IRC): this isn't about
the fatal error; we downgraded this to a nonfatal error in 4698c8f
(config: allow inaccessible configuration under $HOME, 2013-04-12).

Rather, it's very strange that 'git config --file foo' tries to look at
any config file other than 'foo'.  In a git repo:

  $ strace git config --file fooconfig test.var 2>&1 | grep 'open.*config'
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3
  open("fooconfig", O_RDONLY)             = 3

I haven't looked into the code yet.  Probably it's simply following the
usual code paths to discover a repo and read its config.  However, with
the --file option, it shouldn't.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Git --file doesn't override $HOME in version 1.8.1.2

[Junio C Hamano]

Sarajärvi Tony <Tony.Sarajarvi@digia.com> writes:

> Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
>
> In Puppet we launch Git with the command: '/usr/bin/git config --file /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration System"'

Hmph.  What does this even mean?

    git config --get user.name "Qt CIS"

I have a feeling that the command will exit with an error status 1.

> However, puppet logs: "fatal: unable to access
> '/root/.config/git/config': Permission denied".
>
> Puppet is run as root, so HOME points to /root, but still -file
> should override the environment variable.

Probably.

> If the same command is run directly from terminal as root, it works as well.

I am not sure what you mean by "works as well".  It behaves
differently and does not fail the same way?

> With 1.8.3.2 the problem didn't reoccur.

That is probably due to b1c418e1 (Merge branch
'jn/config-ignore-inaccessible' into maint, 2013-06-09)

But it is puzzling.

The "error out upon an inaccessible configuration file in usual
places" check we had since v1.8.1.1 was meant to make sure that you
will not be missing a basic configuration before running any command
(including "git config" itself).  As "root", you shouldn't even have
triggered the "unable to access: Permission denined" in the first
place.  There is something else going on.

RE: Git --file doesn't override $HOME in version 1.8.1.2

[Sarajärvi Tony]

> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: 9. heinäkuuta 2013 15:01
> To: Sarajärvi Tony
> Cc: git@vger.kernel.org
> Subject: Re: Git --file doesn't override $HOME in version 1.8.1.2
> 
> Sarajärvi Tony <Tony.Sarajarvi@digia.com> writes:
> 
> > Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
> >
> > In Puppet we launch Git with the command: '/usr/bin/git config --file
> /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration System"'
> 
> Hmph.  What does this even mean?
> 
>     git config --get user.name "Qt CIS"

Our puppet configuration is available for anyone here:
https://qt.gitorious.org/qtqa/sysadmin/blobs/master/puppet/modules/git/manifests/config.pp

We check with 'unless' if the user.name has been set to what we expect it to be. The return value is different from Git if I typo the name.

root@dev-ubuntu1304-x64-01:~# git config --file /home/qt/.gitconfig --get user.name "Qt Continuous Integration Systed"
root@dev-ubuntu1304-x64-01:~# echo $?
1
root@dev-ubuntu1304-x64-01:~# git config --file /home/qt/.gitconfig --get user.name "Qt Continuous Integration System"
Qt Continuous Integration System
root@dev-ubuntu1304-x64-01:~# echo $?
0

> 
> I have a feeling that the command will exit with an error status 1.
> 
> > However, puppet logs: "fatal: unable to access
> > '/root/.config/git/config': Permission denied".
> >
> > Puppet is run as root, so HOME points to /root, but still -file
> > should override the environment variable.
> 
> Probably.
> 
> > If the same command is run directly from terminal as root, it works as well.
> 
> I am not sure what you mean by "works as well".  It behaves
> differently and does not fail the same way?
> 
Must have been writing something else and changed my mind :) I was trying to say that everything works when run from the command line. The permission denied appears when running with Puppet. And Puppet is run as root. And even if Puppet was run as some other user, I still don't think that Git should be trying to use anything from /root, as we're giving it the --file parameter. As if Puppet removed the whole --file parameter altogether. But as it works with a newer or older version of Git, it can't be dropping the parameter out. Root user is the only one with HOME set to /root, so it must be getting that value from root's HOME variable.

> > With 1.8.3.2 the problem didn't reoccur.
> 
> That is probably due to b1c418e1 (Merge branch
> 'jn/config-ignore-inaccessible' into maint, 2013-06-09)
> 
> But it is puzzling.
> 
> The "error out upon an inaccessible configuration file in usual
> places" check we had since v1.8.1.1 was meant to make sure that you
> will not be missing a basic configuration before running any command
> (including "git config" itself).  As "root", you shouldn't even have
> triggered the "unable to access: Permission denined" in the first
> place.  There is something else going on.

That is also weird, agreed.

Re: Git --file doesn't override $HOME in version 1.8.1.2

[Jeff King]

On Tue, Jul 09, 2013 at 01:49:21PM +0200, Thomas Rast wrote:

> Rather, it's very strange that 'git config --file foo' tries to look at
> any config file other than 'foo'.  In a git repo:
> 
>   $ strace git config --file fooconfig test.var 2>&1 | grep 'open.*config'
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
>   open("fooconfig", O_RDONLY)             = 3
> 
> I haven't looked into the code yet.  Probably it's simply following the
> usual code paths to discover a repo and read its config.  However, with
> the --file option, it shouldn't.

I'm not so sure. It is (in theory) OK to read the usual config files to
find out _how_ git-config should behave, but then return results from a
specific file. The former should read the "normal" files, and the latter
should read whatever is specified by the options ("--file", a specific
level like "--global", or the usual set of files).

There are probably not many config options that can affect git-config's
behavior. The few I can think of are:

  1. core.editor should affect "git config --edit"

  2. pager.config would auto-start a pager. I am not sure if that is a
     sane thing to do or not.

  3. In theory you could have advice.* affect git-config, but I do not
     think any currently do.

  4. Currently git-config does not read objects, but there are patches
     proposed to do so. In that case, things like core.packedGitWindowSize
     might be important.

So I think you could probably drop the config parsing, special-case (1),
and ignore (2) as silly. But I think (3) and (4) show that it isn't the
right thing to do; you will never know which config options affect
git-config's behavior in the future.

The real issue here is not the "extra" normal config parsing; it is that
the normal parsing does not work in some cases. And that has already
been fixed by Jonathan's 4698c8f (config: allow inaccessible
configuration under $HOME, 2013-04-12).

-Peff