FS#56008 - [rsync] ProtectHome=on breaks rsync on homedirs
Attached to Project:
Arch Linux
Opened by Geert Hendrickx (ghen) - Monday, 16 October 2017, 08:44 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 24 June 2020, 13:52 GMT
Opened by Geert Hendrickx (ghen) - Monday, 16 October 2017, 08:44 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 24 June 2020, 13:52 GMT
|
Details
Description:
ProtectHome=on was added to rsyncd unit file in version 3.1.2-4 This obviously breaks rsyncing of home directories between servers (it can no longer even list the /home/* directories). Although this flag is useful for network services in general, I think rsyncd is a bad candidate. Please rollback. |
This task depends upon
Closed by Christian Hesse (eworm)
Wednesday, 24 June 2020, 13:52 GMT
Reason for closing: Not a bug
Additional comments about closing: this is now upstream behavior
Wednesday, 24 June 2020, 13:52 GMT
Reason for closing: Not a bug
Additional comments about closing: this is now upstream behavior
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?
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.
[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 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.
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.
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?
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 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.