File Release Management POC


Technical Choices

  • SFTP as provided by OpenSSH (internal-sftp)
  • FusionDirectory as management backend
  • LDAP authentication using:
    • libnss-ldapd and libpam-ldapd packages
    • pam_ldap
    • nslcd (local LDAP name service daemon)
    • nscd (name service caching daemon)

Functional

authorization (nslcd)

  • nslcd checks if the user, or any group he is part of, is allowed to access the release server. Authorization settings are managed with FD's "trust mode" properties (either on user entry or groups entries). When denied, the user is kicked out (after a successful authentication but before the real login process takes place.)
  • if the above is satisfied and nslcd trusted the user, then
    • the user is restricted to a chroot'd SFTP session (ie, SSH NOT allowed) thanks to a specific SSHD config against *-release membership pattern.
    • if the user is not member of any *-release group, access to the service (SFTP or SSH) is denied and the session closed.

folder organization and chroot

  • When logged in the SFTP service, the working directory is /projects which is the root of the SFTP release repository. Here comes a folder for each project. Note: The question remains what to do when the project's folder doesn't exist yet in the repository.
  • Each folder is owned by the related 'release' group for the project : one can only act on projects he is allowed to.

Limitations

Most unix filesystems handle permissions using UID & GID based on passwd/group databases, which means that everything in fusiondirectory is managed using posixAccount and posixGroup classes & attributes. It imply the creation of an additional 'foo-release' posixGroup in every project branch in case we  we want - as I am planning to - a per-project access management to the SFTP repository.
Besides, in a perfect world as we have a manager role in each project, occupants of this role should inherit this permission. Hence FD doesn't support group of group. It remains possible to get around that using LSC, to populate (periodically) the 'foo-release' group based on the occupants of 'foo-manager' role.

See also

File Release Management Specifications