git credential cache and sudo

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

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

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

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

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 [off-list ref] wrote:

Jeff King wrote:

quoted

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

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

quoted

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