I'm writing a set of scripts to provision game servers.

I have each game server being installed as a separate user, so that they're all isolated and can't access each other's files.

The daemon/server which handles the provisioning runs as an unprivileged user, with sudo permission to create users.

I'm now developing a feature that requires the daemon to be able to edit files on behalf of users after the servers are provisioned.

I was thinking of adding the daemon to a group like "admin", setting the group on all users files to "admin" with group permissions so that the daemon can read and write their files - though leaving the individual users out of the "admin" group so they can't read each others files.

This works on first install, and I can set the setgid bit to ensure that new files and folder inherit the "admin" group. However, it's possible for the users to "chgrp" to their own group, which breaks this system. The daemon can no longer access the files, and even the users cannot revert the group back to "admin" because they do not belong to that group.

Is there a way:

  1. To prevent the game server users from changing the group of their files to anything other than "admin", so the above will work; or
  2. Is there a better way to achieve what I'm trying to achieve here?

1 Answer 1


Ownership access includes the access to set the group-ID, permissions bits, and ACLs; so there is nothing that you can do to stop the owners of a file from setting this stuff.

Of course, hidden in that sentence is the seed of two different approaches:

  1. Do not grant ownership access in the first place. Do not make the user accounts the owners of the files. Instead, use setfacl to grant the individual user accounts rwx (or whatever) access in an ACL. Make them owned by some other account, assigned a group that the accounts are not part of, and not world-accessible. The disadvantages here are things like disc quotas.
  2. Use a form of access control that the owner can turn back on. Make the individual user accounts the owners but use setfacl to grant the dæmon account rw- (or whatever) access in an ACL. The disadvantage here is that the user accounts can turn access off in the first place.

Evaluate the trade-offs according to need. Use default ACLs in the parent directory if you want to automatically set these ACLs on all created files.

Further reading

  • Thank you, this is brilliant. I've gone with your second suggestion, and set ACLs for the daemon account and the user account to always have access to each home directory, so that they can both access files that the opposite has created. Fortunately it's not such a concern that the user could disable the ACLs, as they certainly couldn't do it accidentally - so it's on them if they want to break the system to their disadvantage. Thanks again!
    – ev0lution
    Commented Nov 13, 2017 at 11:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .