-/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 rsync.conf file
-(e.g. "exclude = /etc/"). Note that having the exclusion affect uploads
-is a relatively new feature in rsync, so make sure your server is running
-at least 2.6.3 to effect this.
-
-dit(bf(port)) You can override the default port the daemon will listen on
-by specifying this value (defaults to 873). This is ignored if the daemon
-is being run by inetd, and is superseded by the bf(--port) command-line option.
-
-dit(bf(address)) You can override the default IP address the daemon
-will listen on by specifying this value. This is ignored if the daemon is
-being run by inetd, and is superseded by the bf(--address) command-line option.
+/etc/group, but perhaps additional dynamic libraries as well).
+
+If you copy the necessary resources into the module's chroot area, you
+should protect them through your OS's normal user/group or ACL settings (to
+prevent the rsync module's user from being able to change them), and then
+hide them from the user's view via "exclude" (see how in the discussion of
+that option). At that point it will be safe to enable the mapping of users
+and groups by name using the "numeric ids" daemon option (see below).
+
+Note also that you are free to setup custom user/group information in the
+chroot area that is different from your normal system. For example, you
+could abbreviate the list of users and groups.
+
+dit(bf(numeric ids)) Enabling the "numeric ids" option disables the mapping
+of users and groups by name for the current daemon module. This prevents
+the daemon from trying to load any user/group-related files or libraries.
+Enabling this option makes the transfer behave as if the client had passed
+the bf(--numeric-ids) command-line option. By default, this parameter is
+enabled for chroot modules and disabled for non-chroot modules.
+
+A chroot-enabled module should not have this option enabled unless you've
+taken steps to ensure that the module has the necessary resources it needs
+to translate names, and that it is not possible for a user to change those
+resources.
+
+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 the inside-chroot path is "/", otherwise it is enabled.
+
+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
+that has an inside-chroot path of "/", you should add "/rsyncd-munged/"
+to the exclude setting for the module so that
+a 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
+(or the inside-chroot path is not "/"),
+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(charset)) This specifies the name of the character set in which the
+module's filenames are stored. If the client uses an bf(--iconv) option,
+the daemon will use the value of the "charset" parameter regardless of the
+character set the client actually passed. This allows the daemon to
+support charset conversion in a chroot module without extra files in the
+chroot area, and also ensures that name-translation is done in a consistent
+manner. If the "charset" parameter is not set, the bf(--iconv) option is
+refused, just as if "iconv" had been specified via "refuse options".
+
+If you wish to force users to always use bf(--iconv) for a particular
+module, add "no-iconv" to the "refuse options" parameter. Keep in mind
+that this will restrict access to your module to very new rsync clients.