Some of our team like to do everything via SSH as themselves so to speak (user1) from the cmd line. one in particular noted that if he logs in as as himself “user1” he cannot actually work on a domain such as
/home/coolSite/
as “user1” …-bash: cd: /home/cooSite: Permission denied.
he has to su as root then su as “coolSite” and then touch files. This way the ownership of the files remains “coolSite” which is mission critical because bad things happen to some site apps if the ownership is not the main site user. He has some security concerns and writes me today:
“the suggestion is, we should have a way to work without becoming the superuser (root). generally speaking, it is considered dangeous to work as root, because there are no handcuffs. no audit trail either, who did what? generally speaking, if you want to deny permission to the general public on something but grant permission to a group. you create a group, make certain people only part of the group, and then set directory permissions so they can access stuff. at least in my experience that is how we do it.”
I am wondering if we can do this and if it will break anything. Typically VirtualMin keeps life really simple, which I love! so files in
/home/coolSite/public_html/ are all owned by coolSite and the group is also coolSite.
How should we approach this to meet the requirement to stay away from the superuser.
Can we create a generic group (typical on many systems) “staff” add “user1, user2” etc to group “staff” and then chown all files in /home/coolSite/ (and 5 other sites) to owner: coolSite group: staff
will this break anything? MySQL access, PostgreSQL, SSL, Apache etc.