threads / discuss / 55301

git credential cache and sudo

Subject: git credential cache and sudo

## tl;dr

5 messages between Mar 12, 2021 and Mar 15, 2021.

replies: 4people: 3as markdown or json

John Ratliff· Mar 12, 2021, 16:43 UTC · lore

When I do sudo git pull, git does not know about my credential cache.

On some servers, when I do a sudo -E git pull, it can find my credential cache and use it. On other servers, I think the sudo configuration is stripping the environment, so this doesn't work and I still have to enter my git credentials.

What environment variables do I need to configure sudo to preserve to make sudo -E git pull work with my credential cache? Or is there something else I can pass to git or define to get it to use my credential cache?

Thanks.

--John

Jeff King· Mar 12, 2021, 20:29 UTC · re: John Ratliff · lore

Re: git credential cache and sudo

On Fri, Mar 12, 2021 at 11:43:46AM -0500, John Ratliff wrote:

Show 11 quoted lines

> When I do sudo git pull, git does not know about my credential cache.
> 
> On some servers, when I do a sudo -E git pull, it can find my
> credential cache and use it. On other servers, I think the sudo
> configuration is stripping the environment, so this doesn't work and I
> still have to enter my git credentials.
> 
> What environment variables do I need to configure sudo to preserve to
> make sudo -E git pull work with my credential cache? Or is there
> something else I can pass to git or define to get it to use my
> credential cache?

From "git help credential-cache":

  --socket <path>
    Use <path> to contact a running cache daemon (or start a new cache daemon if
    one is not started).  Defaults to $XDG_CACHE_HOME/git/credential/socket
    unless ~/.git-credential-cache/ exists in which case
    ~/.git-credential-cache/socket is used instead. If your home directory is on
    a network-mounted filesystem, you may need to change this to a local
    filesystem. You must specify an absolute path.

So probably sudo is setting $HOME (even if using $XDG_CACHE_HOME, that defaults to $HOME/.cache).

You can specify arguments to a helper in your config file, like:

  [credential]
  helper = "cache --socket /home/youruser/.git-credential-cache/socket"

which will make the location independent of $HOME.

Note that it's a little funky to be accessing the cache as a different user than the one who created it. This should work reliably when the cache was created by your normal user, but then accessed as root, because root has permissions to access the socket. But if you spawn a cache daemon as root (because the _first_ operation you perform is as root, which automatically starts a daemon to store the cached credential), then it's likely you won't be able to access it as your regular user.

-Peff

Jonathan Nieder· Mar 13, 2021, 02:51 UTC · re: Jeff King · lore

Re: git credential cache and sudo

Jeff King wrote:

Show 7 quoted lines

> Note that it's a little funky to be accessing the cache as a different user than
> the one who created it. This should work reliably when the cache was created by
> your normal user, but then accessed as root, because root has permissions to
> access the socket. But if you spawn a cache daemon as root (because the _first_
> operation you perform is as root, which automatically starts a daemon to store
> the cached credential), then it's likely you won't be able to access it as your
> regular user.

I wonder if this suggests a missing feature in git-credential-cache(1): if the manpage advertised a way to launch the daemon through an explicit command, similar to 'ssh-agent', then a user could run that as themselves before running other commands that communicate with it as another user.

All that said: John, why are you running git as root in the first place? It's likely that it's safer to run git as a different user and use a separate command such as rsync to perform the privileged deploy action.

Thanks, Jonathan

John Ratliff· Mar 15, 2021, 17:24 UTC · re: Jonathan Nieder · lore

Re: git credential cache and sudo

We have a shared git repo for our production puppet environment. I have my own environment for testing things, so my git credential cache is already created as my user before I move things into production. My environment is in a github fork of the production environment though, so I don't think rsync is an option here. It's possible the directory permissions could be ACL'd to enable us not to need sudo, but I do not have the authority to change that myself.

I think I will try referencing the socket and see how that works.

Thanks.

--John

On Fri, Mar 12, 2021 at 9:51 PM Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 24 quoted lines

>
> Jeff King wrote:
>
> > Note that it's a little funky to be accessing the cache as a different user than
> > the one who created it. This should work reliably when the cache was created by
> > your normal user, but then accessed as root, because root has permissions to
> > access the socket. But if you spawn a cache daemon as root (because the _first_
> > operation you perform is as root, which automatically starts a daemon to store
> > the cached credential), then it's likely you won't be able to access it as your
> > regular user.
>
> I wonder if this suggests a missing feature in
> git-credential-cache(1): if the manpage advertised a way to launch the
> daemon through an explicit command, similar to 'ssh-agent', then a
> user could run that as themselves before running other commands that
> communicate with it as another user.
>
> All that said: John, why are you running git as root in the first
> place?  It's likely that it's safer to run git as a different user and
> use a separate command such as rsync to perform the privileged deploy
> action.
>
> Thanks,
> Jonathan

Jeff King· Mar 15, 2021, 18:56 UTC · re: Jonathan Nieder · lore

Re: git credential cache and sudo

On Fri, Mar 12, 2021 at 06:51:53PM -0800, Jonathan Nieder wrote:

Show 13 quoted lines

> > Note that it's a little funky to be accessing the cache as a different user than
> > the one who created it. This should work reliably when the cache was created by
> > your normal user, but then accessed as root, because root has permissions to
> > access the socket. But if you spawn a cache daemon as root (because the _first_
> > operation you perform is as root, which automatically starts a daemon to store
> > the cached credential), then it's likely you won't be able to access it as your
> > regular user.
> 
> I wonder if this suggests a missing feature in
> git-credential-cache(1): if the manpage advertised a way to launch the
> daemon through an explicit command, similar to 'ssh-agent', then a
> user could run that as themselves before running other commands that
> communicate with it as another user.

Perhaps. The daemon side of the credential-cache helper does not work quite like ssh-agent, though, in that it tries to be ephemeral. So after starting, you have 30 seconds to give it some data to cache before it will exit. Normally this is fine since it's started by the client side of the helper, which will then immediately supply it with data.

So after starting it, you'd need to immediately prime it with data, either manually or by running a Git command. And then hope that command, including time to talk to the other side on the network and for you to type your password, does not exceed the timeout.

-Peff