I have set up a user account for my backup user, set group ownership with sticky bit accordingly and chmod the dirs in question. But files created by the seafile-services have the permission set to 600. So future backup jobs with my backup user fail with permission errors. Is there a way to set umask/file creation mask? chmod every time before the backup seems like a bad workaround.
Found this old Thread with no answers. Are there any changes/new infos on this?
If you want do same like guy in thread you posted. I suggest do it in different direction. First I THINK it’s not safe expose data to another users which can remotely connect to your server. Better way for me is connect server to you backup storage and run cronjob or systemd timer to copy files as seafile user. For example I’m using NFS mount + rsync or rsync over SSH. So in first way is backup storage mounted to server whole time and seafile user just rsync files to the mount point. In second way seafile user just call rsync over ssh tunnel to backup storage. Both working for years without big problems.
But can you explain me security reasons for expose data directory? If you push, then your server have access to backup storage and can encrypt backup before push. If you pull then you expose your prod data to someone else(yes it can be you), so you added at least one attack vector to production data which can be encrypted by some ransomware or can be stolen. Maybe I missing something, but for me it’s always better push backup (encrypted as best option) and than you is more protected for some MitM attack or some local permission escalation if backup server is compromised.
I’m not telling you what to do. That’s on you, i’m just curious why is pull-based backup better for you. Maybe I learn something new
The talk is getting a bit off-topic, never the less, it’s interesting.
We prefer pull-based because if the server is high-jacked it is possible for the attacker to mess with the backups. (encrypt, mangle, delete)
Mangle: If this goes unnoticed, your backups are there, but unusable.
(We had a larger attack last year in our area affecting 34 companies, where exactly this happened.)
In regards to Seafile: The files are made group-readable by a cron so the backup-ssh user is allowed to read those.
Backups in general: encrypt them, check them for consistency regularly, practice disaster recoveries, keep them off-site.
I know this is a very old thread at this point but I stumbled across it looking for ways to prevent the Seafile client from changing the permissions on synced linux files.
Anyhow, your idea of a “push” backup method being more secure than a “pull” method is incorrect. Production data is assumed to be writable by many different users/services depending on its use, and if any data is more likely to be encrypted by ransomware, it’s usually production data first. The whole idea of secure backups in this particular scenario is to ensure they cannot also be encrypted.
In that case, using a “pull” method is more secure for backup purposes, as the user/service/groups that can access the production data by default won’t and shouldn’t have any access at all to the backup location. The backup service would have its own unique read-only account within the production environment to pull that data for backing it up, but shouldn’t be able to modify the production data.
If you’d set your backup environment up the way you’re suggesting here, then any account inside the production environment with access to that data would also be able to modify the backup data, which is bad news.
Of course, in the end, you can configure your backup environment however you’d like, but backups should be set up with minimal access permissions to ensure security. Just wanted to address this conversation for any future readers!