On the web front-end
Forge users are registered using a traditional login&password, with a verified e-mail address.
Numerous Plugins also exist to provide external authentication, e.g. via LDAP or CAS.
FusionForge's security model is based directly on the Linux kernel, using POSIX user accounts (privilege separation).
This is done via
libnss-pgsql, which automatically maps a shell account for each user in the PostgreSQL database, if they are part of a project.
User can then securely access their repository via SSH keys, and login to manage their webpages files. If full login is not desirable, it is also possible to install a restricted shell such as
rssh to limit shell access to e.g. Git, SVN and SFTP only.
Each project is similarly mapped to 3 POSIX groups:
- projectname : access to group directory, including webpages
- projectname_scmro : read-only access to source repositories
- projectname_scmrw : read/write access to source repositories
User accounts have appropriate group memberships so they can only access projects for which they have RBAC permissions.
Important: users and groups are not created (i.e. no
useradd) - they are directly mapped to the database through
Web access to repositories
When accessing Git&SVN repositories though HTTPS, FusionForge uses
mpm-itk, an Apache module, where each Apache process is run using the matching shell user account, with appropriate groups memberships.
In particular, repository hooks are securely run under the user's account (i.e. not
Apache doesn't use the database for authentication because modules aren't easily available in all distros. Instead, FusionForge automatically generates:
/var/lib/fusionforge/scm-passwd: users and hashed password using .htpasswd format
/var/lib/fusionforge/scm-auth.inc: declares valid users with repo access (e.g. Git)
/var/lib/fusionforge/scmsvn-auth.inc: declares valid users specificially for SVN access due to
fusionforge-systasksd, automatically regenerates the files and reloads Apache when new users and groups are added or removed, so that repository access is immediately active.
NSCD is the Name Service Cache Daemon. It is used to cache database results for users and groups mapping, for performances reasons. In the case of
libnss-pgsql, it's necessary to install
nscd, to fix an authentication loop when the database is installed on the same server as the shell server.
NSCD is provided either by
nscd (part of
unscd, which is lighter and protects against bugs in NSS modules.
fusionforge-systasksd, automatically clears
nscd's cache when new users and groups are added or removed, so that shell accounts are immediately active.
You shouldn't need to go into these details, but in case you need to plug an external application to the database, here's some information.
Users and groups are mapped on the system as soon as they match the following criteria:
- users: active, member of a project
- groups: approved
When they do, they are added to the
nss_passwd(view) : user accounts
nss_shadow(view) : generally unused, available if you have precise password-authentication needs
nss_groups(table) : groups for projects
nss_usergroups(table) : groups membership
/etc/nss-pgsql.conf for the reference SQL queries.
UID and GID ranges
- In the database:
- user_id start at: 101
- group_id start at: 1
- On the system
- UIDs are (user_id+20000), range 20000-
- GIDs are group_id + base:
- projectname: range 10000-49999
- projectname_scmro: range 100000-149999
- projectname_scmrw: range 50000-99999