Le mercredi 30 juillet 2008, mirror-maintainer at mirror.averse.net a écrit : > On Tue, 29 Jul 2008, Olivier Thauvin wrote: > >>> Your rsync user - don't run rsync as root! And don't run it as your > >>> web/ftp service account either. > >> > >> I can understand not running rsync in daemon mode as root but what is > >> the problem with running the rsync client as root? > > > > There is many reasons: > > [snip] > > Thanks Olivier. Although this question wasn't asked, I'd add a reason not > to run as the web/ftp service account, which is to ensure that the web/ftp > service is unable to access the content if it isn't world readable; eg > when content is made available to mirrors before public announcements, and > a permission bitflip is used to make the content available on the release > date. > > Ironically, I do run rsync --daemon as root for a few reasons: > - use chroot=true chroot does not prevent from privilege gain, it just limit access to the filesystem. IIRC, rsync has suffer in past of bug allowing write access regardless chroot settings. Real exploit rarelly occurs though. > - listen on port 873 rsync does not have any code to listen on a socket. The only way it has to communicate is using pipe with STDIN/STDOUT. Network connection are done either by ssh/rsh, either by (x)inetd. This make as a possible setup starting rsync as normal user, xinetd listening as root on port 873 But rsync need root privileges to perform chroot(), or to perfrom setuid() in case you need to run rsync as different user according share configuration for some reasons. > - specify per-module uid, gid > > Admittedly, I could manually chroot the daemon to the entire mirror > tree before running it as a regular user, and I could do some port > forwarding or iptables stuff and run rsyncd on a high port, and use a > common nobody-like account for all modules... Yes it is possible, of course, but useless, honestly. As all serious server rsync do the best to run a very short time as root. And first things done are chroot && setuid. Moreover, rsync probably need some /dev entry (null, zero, maybe random), you'll have to copy few lib. Well at the end this make the computer hardest to hack, but probably not impossible, remember the kernel is same, kernel can have exploit too. finally it can be safer to let rsync loading all libs in memory and performing itself the chroot over data only tree. > > What do you guys do? I have xinetd, starting rsync as root (for chroot(), not a big deal, rsync switch to normal user as soon root personnality is not need anymore), and in my rsyncd.conf I have: read only = yes uid = nobody gid = nogroup use chroot = yes As default setting. Some of my exported module need others user/group permissions (incoming share), these specific modules have an uid/gid explicitely configured. ps clearly show rsync perform a setuid to become a simple user: 14170 nobody 25 5 23468 3560 1080 D 10 0.0 1:13.25 rsync ftp run as 'nobody' user, web server as 'apache' server. All mirrors are done by a 'distrib' user. So, except upstream setup 777 permissions on some files (FYI: can be override with rsync when you're doing your mirror, see --chmod option), no chance an attackers can write on the mirror tree. In the case a part of the tree is not readable by everyone, I assume it is an upstream choice (the reason you explain at the beginning of the mail). Notice the bitflip can be problematic for tier 2 mirrors, eg mirrors rsyncing from tier 1, they will not have access to the hidden tree, and get an error. In such case, rsync refuse to delete old files. Such situation should shorter as possible, otherwise tier 2 can see their tree growing (usually the tree of a distro stop to move during the release step, developers prefer to sleep after the hard work ;) The mirror I am talking about is http://mirror.ipsl.fr/, often know as distrib-coffee.ipsl.jussieu.fr (but the first name is really shorter :) Best regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos-mirror/attachments/20080730/999d5380/attachment-0004.sig>