sorts of socket options which may make transfers faster (or
slower!). Read the man page for the setsockopt() system call for
details on some of the options you may be able to set. By default no
-special socket options are set.
+special socket options are set. These settings are superseded by the
+bf(--sockopts) command-line option.
enddit()
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
+being downloaded/uploaded by adding an exclude rule to the rsyncd.conf file
(e.g. "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
bf(--include-from) option with a equivalent file.
See the "exclude" option above.
+dit(bf(incoming chmod)) This option allows you to specify a chmod string
+that will affect the permissions of all incoming files (files that are
+being copied to the daemon). These changes happen last, giving you the
+final word on what the permissions should look like in the repository. See
+the description of the bf(--chmod) rsync option and the bf(chmod) manpage
+for information on the format of this string.
+
dit(bf(auth users)) The "auth users" option specifies a comma and
space-separated list of usernames that will be allowed to connect to
this module. The usernames do not need to exist on the local
"auth users" is set then the client will be challenged to supply a
username and password to connect to the module. A challenge response
authentication protocol is used for this exchange. The plain text
-usernames are passwords are stored in the file specified by the
+usernames and passwords are stored in the file specified by the
"secrets file" option. The default is for all users to be able to
connect without a password (this is called "anonymous rsync").
before and/or after the transfer. If the bf(pre-xfer exec) command fails, the
transfer is aborted before it begins.
-The following environment variables are set for both commands:
+The following environment variables will be set, though some are
+specific to the pre-xfer or the post-xfer environment:
quote(itemize(
it() bf(RSYNC_MODULE_NAME): The name of the module being accessed.
it() bf(RSYNC_HOST_ADDR): The accessing host's IP address.
it() bf(RSYNC_HOST_NAME): The accessing host's name.
it() bf(RSYNC_USER_NAME): The accessing user's name (empty if no user).
-))
-
-These environment variables will also be set for the bf(post-xfer exec)
-command:
-
-quote(itemize(
- it() bf(RSYNC_EXIT_STATUS): rsync's exit value. This will be 0 for a
+ it() bf(RSYNC_REQUEST): (pre-xfer only) The module/path info specified
+ by the user (note that the user can specify multiple source files,
+ so the request can be something like "mod/path1 mod/path2", etc.).
+ it() bf(RSYNC_ARG#): (pre-xfer only) The pre-request arguments are set
+ in these numbered values. RSYNC_ARG0 is always "rsyncd", and the last
+ value contains a single period.
+ it() bf(RSYNC_EXIT_STATUS): (post-xfer only) rsync's exit value. This will be 0 for a
successful run, a positive value for an error that rsync returned
(e.g. 23=partial xfer), or a -1 if rsync failed to exit properly.
- it() bf(RSYNC_RAW_STATUS): the raw exit value from waitpid().
+ it() bf(RSYNC_RAW_STATUS): (post-xfer only) the raw exit value from waitpid().
))
Even though the commands can be associated with a particular module, they
are run using the permissions of the user that started the daemon (not the
-module's uid/gid setting) without any chroot restrictions (even if the
-module will/has run chroot()ed).
+module's uid/gid setting) without any chroot restrictions.
enddit()
manpagesection(AUTHENTICATION STRENGTH)
The authentication protocol used in rsync is a 128 bit MD4 based
-challenge response system. Although I believe that no one has ever
-demonstrated a brute-force break of this sort of system you should
-realize that this is not a "military strength" authentication system.
-It should be good enough for most purposes but if you want really top
-quality security then I recommend that you run rsync over ssh.
+challenge response system. This is fairly weak protection, though (with
+at least one brute-force hash-finding algorithm publicly available), so
+if you want really top-quality security, then I recommend that you run
+rsync over ssh. (Yes, a future version of rsync will switch over to a
+stronger hashing method.)
Also note that the rsync daemon protocol does not currently provide any
encryption of the data that is transferred over the connection. Only
Matt McCutchen's Web Site / rsync / rsync.git / blobdiff