Arch Linux

I would like to keep this change. Would be nice if attackers can not access home directories in case it is exploited. Most people do not serve home via rsync I think.

If you want to enable access to home directories create a drop in replacement file /etc/systemd/rsyncd.service.d/home.conf with these lines:

[Service]
ProtectHome=off

Is that a way to go for you?

Yes, I deployed that already, but it's quite cumbersome if people don't know where to start looking.

I do agree it's a very useful protection in general, and I think many more daemons should get it by default, but rsync as a backup tool is probably a special case.

I disagree that the /etc/systemd/rsyncd.service.d/home.conf is a good solution. The reason is the "man rsyncd.conf" with this content:

[ftp]
path = /home/ftp
comment = ftp export area

Thank you for your good work and security thinking! But I think the example from the manual should work.

I agree with Geert and Holger. I use rsyncd to backup 2 boxes over a local network and I think it's a common use case. It took me a lot of time to understand why the various home directories didn't get saved. Moreover, particularly in a system-wide backup scenario like mine, where /home/* is just one of many directories to be saved, one can easily fail to even notice home directories are not getting saved (I noticed it only this morning). I would recommend rolling back, or, at the very very least, add a note to https://wiki.archlinux.org/index.php/Rsync#rsync_daemon

I added the note to the wiki and someone improved it later.
I still would recommend rolling back, but if this is not going to happen I think it would be good if the package warned users during installation/upgrade about the issue with home directories that "ProtectHome=on" introduces, maybe pointing them to https://wiki.archlinux.org/index.php/Rsync#rsync_daemon.

We have instructions in wiki and I added a post-upgrade info.

Hello Christian,

I had also several rsyncd broken by these change. The logic of disabling accesses to some arbitrarily chosen directories because of potential bugs could be applied to a lot of daemon, like http servers and others, and will create useless configuration difficulties.
Rsyncd is a file transfer daemon, adding these options break the regular way of using rsync for theoretical security improvements. That's not the expected behaviour! Not to mention that data can be everywhere else, and with the same logic, we should forbid everything. That already what we do by not starting the daemon automatically (like Debian, etc) after installation.

*sigh*

Looks like this concerns more people than I initially thought. Ok, let's undo the change.

How about ProtectSystem=full? Do we want to keep this or drop it as well?

Sorry Christian for not answering as fast.

ProtectSystem=full is also limiting the expected behaviour of rsyncd; there are read only / write only options in configuration file. If we keep this in the service, this will perturb configuration.
PrivateDevices is also faking the view of the file tree by rsyncd. I think we should not do that too, rsyncd is a file system copy transfer which should not be faked by its service file.

NoNewPrivileges looks like improving security without breaking.

So my opinion would be to rollback at least ProtectSystem, ProtectHome and PrivateDevices.

I agree with Sébastien.
I think the extra layer of security one can get by editing the unit file with ProtectHome/ProtectSystem/PrivateDevices=yes in those cases where it could make sense could be mentioned in a note on the wiki under the "Rsync daemon" paragraph, but should definitely not be enforced upon users by the package's unit file since this interfere with the daemon's expected behaviour.