My server backup folder is set to /var/local/backups/sites. All mail, db, and site .gz files are saved under folders with backupusername 'root' and backupgroup 'root'. The requirement for the root group is harsh. I'd like to get everything under group 'backup' or 'staff' so that users assigned to those groups can access, copy, move, and restore those files. Is there a built-in way to do this? Upcoming enhancement? Should it be done with a custom script or cronjob? From the ISPConfig perspective is there any problem with leaving the group set to whatever we need? Or does ISPConfig need the group 'root' for restore or rotation? Is there anything wrong with changing the group temporarily for operations and then changing it back before the nightly backup that runs from ISPConfig cron? Thanks! [EDIT] I have asked this question before (see tags) but I don't think there has been a firm answer. As you see, the topic keeps coming up. I'm reposting in case something new might be coming - and to avoid a necro-post.
That's for security reasons, as no other user other than root can access these files. If you want to restore a backup, use the restore functions in ISPConfig GUI. Normally, a shell user does not need to access these files if he is not root. Besides doing a restore through ISPConfig, web users can also request access to their web backup, and the backup is then made available in the backup folder of their website so they can access it with their website SSH and FTP user to either download it or do a partial restore manually. Besides that, only the root user would be able to restore e.g. emails correctly with the right permissions if you do not want to use the restore functions in ISPConfig as email files are owned by the user and group vmail, so the user that restores such files must be either root or vmail and as vmail has no shell login, you must be root for that. So yes, you can likely change the owner of backup files and folders manually, but it might get changed back on next backup and you must be aware that you weaken the security of your system and that your non-root users won't be able to restore e.g. emails anyway and web users can already access the backup files using ISPConfig.
You could use sudo and /etc/sudoers, giving trusted users permission to access backup files, and no other root permissions.
Thanks Till and Taleman! The purpose of a group is to fine-tune access for more than one user. Having group 'root' and user 'root' is redundant if we're operating with user root. So the group is there to limit access only for non-root users. In this case, groups 'backup' and 'staff' certainly do not contain clients or other users. So doesn't that tighten the access acceptably? And yes, sudo and /etc/sudoers can do root things. But we don't always have the option to sudo, as when coming in through file management software, so we need to rely on OS-level permissions. In the bigger picture, if we have a 'backup' group and a user assigned to that backup group, we don't want to have to give that user sudo access just to access backups. If we set group access on /var/local/backups/sites to group 'backup' or 'staff', then set the setgid bit, all folders and files under that should then respect the admin-defined permissions. But ISPConfig is doing a chown and chgrp on backups to override this intent. With a non-root group and access 660 on all backups, if ISPConfig runs root or a sudoer, then it can still access all of those files. No one loses in this scenario. Thoughts? Best as always.
I totally can agree on that. Root group might be a secure user in terms of illegimate access however tasks related to the backups in turn needs to run as root aswell, which can ruin the security again.
I would prefer keeping the file and directory permissions and owners as is. If using sudo is not suitable, what about ACL, Access Control Lists.
You mean doing some magic with xattr or namespaces? They can differ on the various systems used and are not guaranteed to be available. Also depends on the filesystem beeing used to store backups.
No, ACL. On Debian it is package acl. Wikipedia has entry: https://en.wikipedia.org/wiki/Access-control_list
he yeah well, I think it is fair to mention that acl is storing them in extended attributes =) But yes, it can be a valid individual solution
@Taleman I agree that ACL is valid, setting access on my /var/local/backups/sites. I'd appreciate your overall thoughts related to the following points: Setting ACL is a manual step outside of of ISPConfig. It wouldn't take much effort to add a text box to the server config for the Backup Group. Changing the backup group does not affect ISPConfig save/restore at all. After creation of the tar/gz the chgrp just needs to use the admin-defined group or default to root as it does now. Or with setgid bit set, no chown/chgrp needs to be done at all. Why specifically do you prefer the group to be root, given that a non-root system-level group works just as well and root:root is redundant security. Is this a "it works, let's not change it" feeling? Unless this discussion goes in another direction, I'll look at two options now : ACL (preferred) or cron a process to change the group of backup files after their creation. As they cycle, each of these files is simply deleted by ISPConfig and new files with group root replace them. I'm fine with that.
Well, if you do the work to write a cron, you could write a postif for ispconfig updates, server/lib/classes/backup.inc.php I think it is, where the root user is hardcoded as owner if the backup shall not be included in a users quota. look for $backup_username and $backup_group = That's all I can add for now I guess
Yeah, note from the title of this thread and the OP, the reference to the variables in the code. I've been in there and would consider enhancing, but I came here to ask about the topic before doing so. I'm still running 3.2.2 and haven't checked the latest .11p2 code to see if that area was already enhanced. TY
