handling of 'use chroot'

[Martin Pool]

At the moment, if you start an rsyncd that's not running as root using
default settings it will have some trouble.  rsyncd tries to use
chroot by default, but this will always fail if it's not started by
root.  It does emit an error message in this case, but I wonder if
some people find this a bit confusing until they discover the setting.
I have in the past.

It might be better that if attempting the chroot gives permission
denied (because the server is not running as root), then it should go
ahead and use the fake-chroot function.  Assuming no security holes in
rsync, the behaviour should be the same.  This is consistent with the
handling of the 'uid' and 'gid' parameters, which are ignored if the
server is not started by root.

The problem is that then people might think they have the protection
of chroot, but actually not do so.

At the moment I think the course that is most friendly to new and
existing users is:

 * 'Use chroot' is slightly redefined to mean 'insist upon chroot'

 * The default option is 'use chroot = no', rather than yes.

 * Regardless of the setting, rsync always tries to chroot to the
   module base directory.

 * If chroot fails:

   - If 'use chroot' is no, then rsyncd uses the fake chroot system

   - Otherwise it fails as it currently does

In this case:

 * People running rsync as root get the same protection they currently
   do.

 * People who install rsync as non-root get a more friendly
   installation and no less security.

 * People who want not to use chroot even when running as root will
   lose.  The only real reason I can think of to do that is that
   chroot might be broken on your machine, e.g. because name
   resolution doesn't work after chrooting.

If we want to allow people the choice even when running as root we
could change 'use chroot' from just being binary to being 'yes', 'no',
'if-possible', or something similar.

Another alternative is to 

 * Leave the default as 'yes'

 * If not running as root, and 'use chroot' is true, then just give a
   warning rather than aborting.

Any comments?

-- 
Martin