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@xxxxxxxxx> wrote: > > 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
