0

A team want to implement a crude file dump backup solution to be used by multiple hosts. They have a remote user on the backup server backupusr that they can SSH/SCP with, with SSH keys setup.

The directory hierarchy on the backup server is: 

-/data/
  -backups/
    -host1/
    -host2/
    -host3/
    ...

I would like the backup user to be able to write files into a host directory but not delete files once they are written.
Is there any way of doing this without using xattrs to set to immutable?

I can't get either setgid or a default ACL/mask working because once a file is copied in it is owned by backupusr which can always delete its files.
So I'm probably looking at a way to change owner and then I could use the stickybit.

Any suggestions?

batfastad
  • 1,035
  • 2
  • 13
  • 24
  • 1
    are you looking to prevent scp from clobbering files, or prevent the user from modifying/removing their own files once stored (if say, they logged in and were browsing the directory)? Also worth noting, the permission to delete a file actually comes from being able to write the directory, because you're actually removing the hard link to the inode from the directory, and if no hard links remain then the inode can be reused. – Centimane Jun 06 '16 at 16:10
  • 1
    Related: [Allow owner to create & read files, but not modify or delete](http://unix.stackexchange.com/questions/222738/allow-owner-to-create-read-files-but-not-modify-or-delete) – Mark Plotnick Jun 06 '16 at 17:50
  • @Dave Looking to prevent the user from modifying/removing their own files once stored. I knew write was required but thanks for the additional detail about the inode... a good one for an interview ;) – batfastad Jun 06 '16 at 19:45
  • Hmm `bindfs` looks interesting. Is there nothing I can do with a combination of `setgid`, `setuid` and ACLs? (I can't think of one!) – batfastad Jun 06 '16 at 19:51
  • 1
    @batfastad I haven't worked with ACLs before, but it looks as though they would still pair writing and deleting as a single permission. I assume you don't want the user to be able to modify the file once copied over (else they could copy over an empty file, which is essentially deleting). In which case your best bet would be for the user to not own the files they transfer. You could either use a different transfer service (maybe ftp? or maybe http) that would receive the file and store it as its own user, or have a cronjob that copies files from a temp location to the actual (probably worse) – Centimane Jun 07 '16 at 10:42
  • @Dave Yes you're right. The problem is that the creator of the file is the owner and can therefore delete. ACLs don't override that fundamental fact. At the moment I think the best way is probably to run a `find ... -mmin +5 -exec chown backupstor: {} \;` every 5 minutes to change the owner and group so the transfer user no longer has permission. Anything else is probably overcomplicating things. Moving the files to a separate tree or using a transfer mechanism instead of `scp/rsync` is probably going to cause more problems than a simple `cron ... chown`. – batfastad Jun 07 '16 at 14:06
  • 1
    @batfastad `cron ... chown` might be simpler, but is not as intuitive. Probably even better would be to automate the backups entirely, and have the a `backup` user with a `cronjob` to perform the `scp/rsync`. Unless backups are needed on an intermittent basis. Even if they are needed on an intermittent basis, a script that can only be run as the `backup` user and a `sudo` permission could be the way to go. – Centimane Jun 07 '16 at 14:25

0 Answers0