Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#40466 - [rsync] removing user and group from rsyncd@.service

Attached to Project: Arch Linux
Opened by Leonard de Ruijter (leonardder) - Tuesday, 20 May 2014, 12:45 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 16 May 2015, 12:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Rsyncd.service does not have the user= and group= restrictions which are in rsyncd@.service. Is there a particular reason for this? It seems the uid and gid options in /etc/rsyncd.conf are able to change uid and gid of the process. Furthermore, i think the systemd service and socket activation pathways shouldn't differ in this. Or am i mistaken here?

I suggest removing user and group from rsyncd@.service
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 16 May 2015, 12:31 GMT
Reason for closing:  Fixed
Comment by Doug Newgard (Scimmia) - Friday, 15 May 2015, 03:49 GMT
Ping Pierre...
Comment by Pierre Schmitz (Pierre) - Friday, 15 May 2015, 12:31 GMT
@Jan: Do you know why this was done? What's the point of the @.service anyway? (Maybe as a reference see http://pkgs.fedoraproject.org/cgit/rsync.git/tree/)
Comment by Jan Alexander Steffens (heftig) - Friday, 15 May 2015, 14:23 GMT
rsyncd.service always needs root since the default port is privileged. I think the point was that since rsyncd@.service gets its socket from systemd there is no need for it to be root.

On the other hand, this prevents rsyncd from changing the user on a per-module basis. However, for this case the user can still override with User=root Group=root.

So the tradeoff of the default configuration is a bit of defense-in-depth for the price of being forced to the nobody user.

I guess you can remove the two lines.

Loading...