Nextcloud version: 18.0.4
Operating system and version: Ubuntu 18.04
Apache version: 2.4.29
PHP version: 7.2
Hey guys, hope you are doing well.
I want to do nightly backups of my nextcloud instance to a remote server using a bash script that I’ll call by a cronjob.
Because I don’t want to break anything, I created a new user on my machine named nc-backup. The idea is to let the bash script be run as the user nc-backup and to give nc-backup only read permissions to all the directories that shall be backed up. So I added backup to the group www-data and changed the permissions of the nextcloud data dir so that members of the group www-data can only read from this directory (the owner www-data ofc still has full access)
The problem I am facing is that nextcloud maintenance mode may only be enabled by the www-data user. Before backing up I want my script to enter maintenance mode and then disable it once the backup is done. I can’t use sudo since it requires a password and I don’t want to put the user password into the bash script.
Is there any way to do this or should I rather run the script as root user?
I think it is not a good idea and modify nextcloud structures like user and group permissions. Perhaps with the next update you get problems.
You can use the www-data-user for backup all files.
I do not know which user (root or www-data) can dump the database.
But root can perhaps dump the database in the nextcloud-file-structure and www-data can sync it to a backup system.
I thought it would be best-practice to create a dedicated user for the backup job but I may have been mistaken.
Could I run into any problem using www-data for this job, then? www-data will get a private certificate to login into the remote machine via sftp. Also, I need to store the password for the remote backup repository (I am using a tool named restic for backups) on the users account, which would also be www-data.
This feels a little odd, since if www-data gets comprimised in any way, they would also gain access to the remote server and my backup repository.
Using root feels weird too, because the user is so powerful that any bug in the tool used for backing up might permanentely destroy data since root has full access anywhere.
You do not need logon for the user www-data with ssh or sftp. The user www-data should use CRON. You do not need a certificate for login … you do not need login and should not login because of security reason.
The user www-data can copy the backup to the backup-server and not the other directive.
Do not open your system for backups.
I think you can dump the database with the www-data-user.
use the settings from your nextcloud installation for database-parameter.
You can find them in config/config.php.
Hope you do not need the database-root-user (not linux-root).
Linux user management:
You can create a normal user (e.g. philosophicalgnu) and only allow the user ssh and sftp to your system. Then you sudo to root and then sudo to www-data. You can set it in /etc/sudoers.
You must differ between:
normal users (people)
application user (e.g. www-data)
system user (root)
Ok. Normal users are not really necessary.
sudo to root and www-data is not really correct.
It is more su to root. But you can use “sudo -s” to root and “sudo -u www-data” (from root).
I think you misunderstood: I want to backup to another machine using SFTP. To secure the other machine (which needs an ssh port exposed to the internet in order to connect), I disabled ssh login via password. Only certificate login is possible.
This means I need to generate a ssh certificate key pair and install the private key for the www-data user and the public key on the backup server.
I think you are right about that, thanks.
I think I’ll just call the backup script as the user www-data, should work fine then.
If I understand correctly (and I’m still kind of newbie with linux), the whole point of the www-data user is that, if that user gets compromised in any way through the webapp, it does not have root privileges on the system.
I feel like it should be the same for the backup user. If I use www-data to do the backups aswell, I need to give www-data privileges to automatically (per script) login into my remote server and store data there.
So if www-data gets comprimised, the attacker would also get access to the backup account on my second server and would be able to delete/download all the backups there, since the backup account would need write permissions on the backup server.
Right now, the only thing stopping me from running the backup script as another user is the need to run occ maintenance:mode --on as www-data. Isn’t there any way to allow the backup user to run sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on (and nothing else, just this command for turning maintenance mode on and off) without a password prompt (since that would not be scriptable)?
Actually the opposite is true. Typically elevated access is needed to run a full system backup. This is true of both Linux and Windows.
Otherwise, each user could only back up their own data (www-data can back up Apache, nextcloud sql user can back up nextcloud sql db), and none of them would have full access to system files.
Makes sense. So you are implying I should use root for backing up instead?
Right now, I’m looking into giving the backup user sudo rights to run specifically the necessary backup commands as www-data (e.g. turning maintenance mode on and off). This would mean elevated access but restricted to the necessary commands only.
I think this might be a good approach since
there is no need to use the all-mighty root user,
a compromised www-data user doesn’t mean my backup server is compromised too (since they don’t have the ssh certificate to login), and
the backup user does not have root privileges to the whole system.
That’s fine if you can make it work. You may end up running separate backup jobs for Nextcloud’s data and for the database since the www-data user probably doesn’t have SQL access.
I’m just saying, you can run a full system backup that won’t be much bigger instead of a piecemeal backup of only the bare essentials. One that could do a bare metal or whole VM restoration. Running a full system backup as root is a common practice and generally not dangerous.
if you want reliable and functional backups and have no requirement for really high-grade security, use root (carefully, though!). if you use application-users for stuff, remember that they usually do not have real shells. also, watch out for file-ownership and perms.
you have fine-grained control over special stuff you can allow certain users to do with /etc/sudoers (man sudoers).
you could write a backup-script as root and if it works, allow you backup-user to run it via sudo.
BTW, allowing a user to run ALL commands via sudo (the *buntu way) is NOT secure.
GOOD LUCK!
Hello @PhilosophicalGnu
I would say your idea is good.
One - or two/three - remarks:
in the database you can create a user that has read-only rights for the nextcloud db from localhost only and using without pw just for mysqldump.
for the maintenance mode you can create an entry in the sudoers file, that gives the backup user the right to sudo (precisely) the maintenance command as www-data without using a pw
with backup-user in the same group as www-data the file backup is also fine without touching the rights of www-data.