+holes, but it has the disadvantages of requiring super-user privileges,
+of not being able to follow symbolic links that are either absolute or outside
+of the new root path, and of complicating the preservation of usernames and groups
+(see below). When "use chroot" is false, rsync will: (1) munge symlinks by
+default for security reasons (see "munge symlinks" for a way to turn this
+off, but only if you trust your users), (2) substitute leading slashes in
+absolute paths with the module's path (so that options such as
+bf(--backup-dir), bf(--compare-dest), etc. interpret an absolute path as
+rooted in the module's "path" dir), and (3) trim ".." path elements from
+args if rsync believes they would escape the chroot.
+The default for "use chroot" is true, and is the safer choice (especially
+if the module is not read-only).
+
+In order to preserve usernames and groupnames, rsync needs to be able to
+use the standard library functions for looking up names and IDs (i.e.
+code(getpwuid()), code(getgrgid()), code(getpwname()), and code(getgrnam())). This means a
+process in the chroot namespace will need to have access to the resources
+used by these library functions (traditionally /etc/passwd and
+/etc/group). If these resources are not available, rsync will only be
+able to copy the IDs, just as if the bf(--numeric-ids) option had been
+specified.
+
+Note that you are free to setup user/group information in the chroot area
+differently from your normal system. For example, you could abbreviate
+the list of users and groups. Also, you can protect this information from
+being downloaded/uploaded by adding an exclude rule to the rsyncd.conf file
+(e.g. "bf(exclude = /etc/**)"). Note that having the exclusion affect uploads
+is a relatively new feature in rsync, so make sure your daemon is
+at least 2.6.3 to effect this. Also note that it is safest to exclude a
+directory and all its contents combining the rule "/some/dir/" with the
+rule "/some/dir/**" just to be sure that rsync will not allow deeper
+access to some of the excluded files inside the directory (rsync tries to
+do this automatically, but you might as well specify both to be extra
+sure).
+
+dit(bf(munge symlinks)) The "munge symlinks" option tells rsync to modify
+all incoming symlinks in a way that makes them unusable but recoverable
+(see below). This should help protect your files from user trickery when
+your daemon module is writable. The default is disabled when "use chroot"
+is on and enabled when "use chroot" is off.
+
+If you disable this option on a daemon that is not read-only, there
+are tricks that a user can play with uploaded symlinks to access
+daemon-excluded items (if your module has any), and, if "use chroot"
+is off, rsync can even be tricked into showing or changing data that
+is outside the module's path (as access-permissions allow).
+
+The way rsync disables the use of symlinks is to prefix each one with
+the string "/rsyncd-munged/". This prevents the links from being used
+as long as that directory does not exist. When this option is enabled,
+rsync will refuse to run if that path is a directory or a symlink to
+a directory. When using the "munge symlinks" option in a chroot area,
+you should add this path to the exclude setting for the module so that
+the user can't try to create it.
+
+Note: rsync makes no attempt to verify that any pre-existing symlinks in
+the hierarchy are as safe as you want them to be. If you setup an rsync
+daemon on a new area or locally add symlinks, you can manually protect your
+symlinks from being abused by prefixing "/rsyncd-munged/" to the start of
+every symlink's value. There is a perl script in the support directory
+of the source code named "munge-symlinks" that can be used to add or remove
+this prefix from your symlinks.
+
+When this option is disabled on a writable module and "use chroot" is off,
+incoming symlinks will be modified to drop a leading slash and to remove ".."
+path elements that rsync believes will allow a symlink to escape the module's
+hierarchy. There are tricky ways to work around this, though, so you had
+better trust your users if you choose this combination of options.
+
+dit(bf(max connections)) The "max connections" option allows you to
+specify the maximum number of simultaneous connections you will allow.
+Any clients connecting when the maximum has been reached will receive a
+message telling them to try later. The default is 0, which means no limit.
+A negative value disables the module.
+See also the "lock file" option.
+
+dit(bf(log file)) When the "log file" option is set to a non-empty
+string, the rsync daemon will log messages to the indicated file rather
+than using syslog. This is particularly useful on systems (such as AIX)
+where code(syslog()) doesn't work for chrooted programs. The file is
+opened before code(chroot()) is called, allowing it to be placed outside
+the transfer. If this value is set on a per-module basis instead of
+globally, the global log will still contain any authorization failures
+or config-file error messages.
+
+If the daemon fails to open to specified file, it will fall back to
+using syslog and output an error about the failure. (Note that the
+failure to open the specified log file used to be a fatal error.)
+
+dit(bf(syslog facility)) The "syslog facility" option allows you to
+specify the syslog facility name to use when logging messages from the
+rsync daemon. You may use any standard syslog facility name which is
+defined on your system. Common names are auth, authpriv, cron, daemon,
+ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0,
+local1, local2, local3, local4, local5, local6 and local7. The default
+is daemon. This setting has no effect if the "log file" setting is a
+non-empty string (either set in the per-modules settings, or inherited
+from the global settings).
+
+dit(bf(max verbosity)) The "max verbosity" option allows you to control
+the maximum amount of verbose information that you'll allow the daemon to
+generate (since the information goes into the log file). The default is 1,
+which allows the client to request one level of verbosity.
+
+dit(bf(lock file)) The "lock file" option specifies the file to use to
+support the "max connections" option. The rsync daemon uses record
+locking on this file to ensure that the max connections limit is not
+exceeded for the modules sharing the lock file.
+The default is tt(/var/run/rsyncd.lock).