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.
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.
2 thoughts on “Getting user groups and UMASK to work on the Raspberry Pi”
Sadly GitBlit is not without bugs. Either that or my setup is not quite right. It’s nice to have the pretty web pages, but I can do well with just SSH access and the client tools such as gitk.
I am very impressed with Git as a version control system. GitBlit offers an interesting working mode in which each developer has their own fork of the main repository and works in that fork. Code can be pulled to the main repository, perhaps as part of a code review process. Developers can pull changes from each other to share work in progress. I’ve not used this in anger, though I have used push and pull to move code between copies of repositories. Git seems able to keep track of all of the branching and merging, something that I’ve not seen work well in SVN.
Excellent article, thanks for this!
This really helped me where I needed to know how to get the umask working and also the sticky bit I needed as well – just awesome! I’m sharing a USB drive via NFS on my Pi for other Pi XBMC clients, using MySQL for central DB on this Pi server… Now the users have rw access via SMB and the group and permissions stay, so if they add new files – anyone part of the group still has rw access..
Works great, thank you again!