I have the GitBlit server on my PI. It’s a little slow at times, especially when we add in the SSL layer. It could work faster with decent disk IO. I think a big bottleneck on the PI is the SD card.

I allow both GitBlit and the much faster SSH access to my GIT repositories. I’m the only user, so I don’t mind that I can also use SSH interactively. It does mean that I need to have permission set up well.

• GitBlit runs within Tomcat, so runs as user tomcat7
• I am my own user.

I created a group “git” and added myself and tomcat7 to it. I configured GitBlit to store its data on the external USB stick in /media/stick/gitblit. (This is backed up daily to DropBox using a backup script.) I ensured that the “git” directory was owned by group “git”, group read write and group sticky. This means that any files or directories created will be owned by the group.

sudo addgroup --system git
sudo adduser tomcat7 git
sudo adduser richard git
cd /media/stick/gitblit
sudo chown -R tomcat7.git git
sudo chmod -R g+ws git

A problem here is when a file is created its permissions are set by the “UMASK”. This defaults to 022, an octal number representing the permissions to disable. Written out long form it is — -w- -w-, so disable write access to group and others. We want members of the git group to be able to write, so we need 002 or — — -w-.

In the old days the UMASK was set in /etc/profile. The /etc/profile now contains a comment to check in /etc/login.defs, which I did and dutifully set the UMASK. It didn’t help.

# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
ERASECHAR       0177
KILLCHAR        025
UMASK           002

The pam_umask module was not enabled on my system. I don’t believe this is something I did. I added it to the end of /etc/pam.d/common-session and common-session-noninteractive.

# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session optional                        pam_ck_connector.so nox11
# end of pam-auth-update config
session optional        pam_umask.so    usergroups

Note the “usergroups” option which is designed for this scenario. I checked that the PAM configuration was OK by logging in again, and checking umask using the umask command.

sudo login

Is it secure? Modern Debian systems place each user in their own group by default, so I create files with user=richard and group=richard. I am the only member of my group, so granting group write access is not dangerous for me.