1

I'm trying to get a fairly simple deploy process going for a Node app using Gitolite. I have Gitolite setup and working on my server, and I'm able to push to it fine.

Gitolite is running under a user called git, and I've setup a node user that I'm hoping to use to run the Node app.

My plan is to push the Node app to Gitolite, and then use a post-receive hook script to move the app files to the directory where the app lives, in this case /var/local/node-apps/my-node-app/. I created the Node app folder like this:

sudo mkdir -p /var/local/node-apps/my-node-app
sudo chown node /var/local/node-apps/my-node-app

The problem is that I'm a Unix noob and I haven't got my head round file/folder permissions and wotnot.

/var/local/node-apps (and also /var/local/node-apps/my-node-app) is owned by the node user, so when the git user tries to checkout to this location I get a bunch of permission denied errors. The command I'm using in the post-receive is:

GIT_WORK_TREE=/var/local/node-apps/my-node-app git checkout -f

And I get errors like this:

remote: error: git checkout-index: unable to create file XXXX (Permission denied)
remote: fatal: cannot create directory at 'XXXX': Permission denied

What's the best way to resolve this? Do I need to grant the git user password-less sudo rights to su as the node user? Or can this be somehow fixed by changing groups and folder permissions? Or a different approach entirely? I'm lost!

Thanks!

Jed Richards
  • 12,244
  • 3
  • 24
  • 35

1 Answers1

0

Using sudo would certainly work, you have one example at "post-receive hook permission denied “unable to create file” error", wrapping the git commands in a script.

Changed post-receive to:

sudo sh /usr/local/sbin/prgetsimpleappscom

Changed sudoers with visudo

git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom

The other approach would be a cron job as node user regularly fetching and (if there are new commit) pulling in the destination repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks! In the example you referenced the guy basically fixed his problem by adding to the sudoers file. Are there any security implications to consider with his approach? – Jed Richards Sep 18 '12 at 17:45
  • @Wintamute the script (referenced in the `suoders` file) needs to be controlled by root (in order to ensure it cannot be changed to do anything else than what it is supposed to do). Beside that, you have the usual pros and cons of using sudo: http://serverfault.com/questions/140633/security-issue-of-linux-sudo-command – VonC Sep 18 '12 at 17:54
  • Ah, I see, makes sense. He actually appends three lines to `sudoers` in his example. `git ALL = (root) NOPASSWD: /usr/local/sbin/prgetsimpleappscom`, `git ALL = (root) NOPASSWD: /bin/sh` and `git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom`. Are all three necessary? – Jed Richards Sep 19 '12 at 09:17
  • @Wintamute I din't test directly, but I believe they might be needed, in order for the script (and the git commands) to execute properly as sudo. – VonC Sep 19 '12 at 09:24
  • I just did a quick test and everything seemed to work with just the final line `git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom`. Am I right in thinking that that final line locks down the `git` user to only being able to run the `/bin/sh` command as root without a password *and* only with the argument `/usr/local/sbin/prgetsimpleappscom`? In which case it seems like a good idea to minimise the changes to `sudoers` to just this (from a security perspective)? – Jed Richards Sep 19 '12 at 10:31
  • @Wintamute yes, you are right. In this case, minimizing the number of authorized commands in the `sudoers` is safer. – VonC Sep 19 '12 at 10:49