Gotcha, all set.

Thanks, Adam

GCIA, GCIH, GCFA, RHCE

Systems Engineer Green Mountain Access http://www.gmavt.net/ Phone: (802) 496-8579 Fax: (802) 329-8579

mirror-maintainer@mirror.averse.net wrote:

On Tue, 29 Jul 2008, Adam wrote:

...

I have one question/issue:

When I hit a different server for example centosi2 vs centosq it resets the numeric user ID from 500 to 501 and back and forth. I take it there is probably a user name associated with the files. If so what would that user name be?

Your rsync user - don't run rsync as root! And don't run it as your web/ftp service account either. _______________________________________________ CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror

Le mardi 29 juillet 2008, Mike Zanker a écrit :

On 29/07/08 15:58, mirror-maintainer@mirror.averse.net 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:

1) do you use your computer for regular action as root ? 2) rsync can have bug, and it is dedicated to massively create or removing files, isn't safer to run it as normal user just in case ? 3) on the remote tree, the sys admin can create setuid executable, devices files etc... with permissions of it own choice. All those files will be nicelly synch to your server with their permission. Running it as regular user will deny creation of device files, and in worst case give to a runnable as this user setuid executable, but in all case, not setuid over root. 4) rsync run as root can keep UID/GID as is, w/o checking who are the user with these UID/GID on your own system, which can give permission to someone untrusted on your side to modify/delete the mirror.

Finally: 5) spliting action through several _normal_ user can limit breakage in case security hole in one of all those services.

Best regards.

Le mercredi 30 juillet 2008, mirror-maintainer@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.

Le mercredi 30 juillet 2008, Brandon Davidson a écrit :

...

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.

Have you read the man page lately?

    Rsync can also be run as a daemon, in which case the following

options are accepted:

         --daemon                run as an rsync daemon

True, last version can be run as standalone daemon. But this option mean nothing about this. --daemon were used for a long time just to specify it is launch from xinetd.

Keld Jørn Simonsen wrote:

...

What do you guys do?

I would also like to run rsync as non-root, although I run it as root now.

I would like to do:

start rsync standalone connect to port 873 possibly chroot run as nobody

Is that possible? I understand that rsync changes from root to some non-root uid when it starts transferring, but in the mode where it processes commands there is a window of opportunity to make it do things. I would then like to close that window.

Why not use xinetd? That's what it's designed to do.

-hpa

Keld Jørn Simonsen wrote:

I would also like to run rsync as non-root, although I run it as root now.

I would like to do:

start rsync standalone connect to port 873 possibly chroot run as nobody

Is that possible? I understand that rsync changes from root to some non-root uid when it starts transferring, but in the mode where it processes commands there is a window of opportunity to make it do things. I would then like to close that window.

Nevermind the previous message. If you want to chroot, you have to run as root -- capabilities could be used to close that hole, though, but I don't think that's supported in rsync yet.

-hpa