User accounts

From FusionForge Wiki
Jump to: navigation, search

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.

Shell accounts

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 (they don't need shell access otherwise).

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 libnss-pgsql.

The workflow is:

fusionforge database > nss_groups table > libnss-pgsql module > /etc/nss-pgsql.conf > nscd > unix user

SSH keys

To be reactive, SSH keys are not stored on the filesystem; instead sshd directly looks them up in the database, using the ssh_akc.php wrapper. You can test this manually:

# /usr/share/fusionforge/bin/ssh_akc.php user_login
ssh-rsa AAAAB3NazC1yc2EAAAABJQA...
ssh-rsa AAAAB3NzaC1yc2EAAAADAQB...


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 [1] [2].

NSCD is provided either by nscd (part of glibc), or unscd, which is lighter and protects against bugs in NSS modules.

FusionForge's daemon, fusionforge-systasksd, automatically clears nscd's cache when new users and groups are added or removed, so that shell accounts are immediately active.

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/www-data).

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 mod-svn idiosyncrasies

FusionForge's daemon, 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.

Database schema

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_* tables:

  • 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

See /etc/nss-pgsql.conf for the reference SQL queries.

See also