rsync as root (Was: [CentOS-mirror] New Mirror)
nanardon at nanardon.zarb.org
Wed Jul 30 03:08:07 UTC 2008
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:
> 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
> 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
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 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.centos.org/pipermail/centos-mirror/attachments/20080730/999d5380/attachment.bin
More information about the CentOS-mirror