File Permission on Seafile Data for Backup User

Hey all,

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?


TLDR; no

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.

Well, you’re describing a push-based backup strategy. The server is pushing the data towards the backup-storage.

We are running a pull-based approach. The backup-server is pulling the data in. (for security reasons)

As I said. No way.

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 :slight_smile:

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.