Best practice for managing access on a shared account?

Question

Our company has a web server for dev and each of our developers has a user account on it. The server also has an account for the user 'app'. The user 'app' does not belong to a single person --- it's a shared account that any developer may use to deploy code that's ready for QA. Code ready for testing gets uploaded to /home/app/public_html/

We're trying to figure out an effective system for managing access to this shared account. Currently, we all just share the password for the 'app' user -- which is bad for a number of reasons.

We'd like to have a system where the developers can still use SFTP or FTP to upload files directly into the 'app' user account. We thought of modifying the group on /home/app and sub-folders so that members of the 'wheel' group would also have permission to add, modify and delete files. However, you then run in the issue of files uploaded by users into /home/app are not owned by 'app' but instead owned by the user who uploaded them.

Are there any best practices for managing access to a shared account?

Answer 1

The best practice for managing shared accounts is to lock the shared account.

Rather than managing access to a shared account - which is bad for many reasons, you should add all of your developers to a group (ie. app_development), testers to another group (ie. app_testing), etc. Once you have users (each of which is only used by a single person) placed in groups according to the jobs and/or tasks they are currently doing, grant the groups appropriate permissions for the files.

For this example, a software developer employed to develop webapps would belong to software_development and web_development (a developer working on local applications might belong to application_development rather than web_development). A tester/QA member of the team would belong to software_testing and web_testing groups.

Users in group wheel always have permission to read and write via root (unless you're directly limiting their access to it with SELinux).

sudo -i
groupadd software_development
groupadd web_development
groupadd software_testing
groupadd web_testing
mkdir -p /home/software_development/web_development/staging`

POSIX Access Control Lists

Make a directory structure for collaboration, giving minimum permission to groups

chown -R root:software_development /home/software_development
chmod 550 /home/software_development
setfacl -m g:software_development:r-x /home/software_development
setfacl -m g:software_testing:r-x /home/software_development

chown -R root:web_development /home/software_development/web_development
chmod -R 2570 /home/software_development/web_development
setfacl -R -m g:web_development:rwx /home/software_development/web_development
setfacl -R -m d:g:web_development:rwx /home/software_development/web_development
setfacl -m g:web_testing:r-x /home/software_development/web_development
setfacl -m d:g:web_testing:0 /home/software_development/web_development
setfacl -m d:g:web_testing:r-x /home/software_development/web_development/staging
setfacl -R -m d:u:root:r-x /home/software_development

1. root and anyone in the groups software_development or software_testing can get into /home/software_testing and see its contents.
2. All web_developers can see and modify the contents of /home/software_development/web_development and all subdirectories (both ones that currently exist and all that may be created in the future).
3. All web_testers can see the direct contents of /home/software_development/web_development, but not any subdirectories except for staging.
4. Note that web_testing and software_testing have no write access whatsoever - as they do not need it to do their jobs.

It is important that the web developers understand that their projects should be placed within a subdirectory of web_development (usually a project name: ie. web_development/project_1, thus denying access for testers to see the currently-in-deveopment source. When it is ready for testing/QA, they would copy it to the staging subdirectory.