Allow some pre-/post-xfer exec shell restrictions.
[rsync.git] / rsyncd.conf.yo
1 mailto(rsync-bugs@samba.org)
2 manpage(rsyncd.conf)(5)(28 Jan 2018)()()
3 manpagename(rsyncd.conf)(configuration file for rsync in daemon mode)
4 manpagesynopsis()
5
6 rsyncd.conf
7
8 manpagedescription()
9
10 The rsyncd.conf file is the runtime configuration file for rsync when
11 run as an rsync daemon.
12
13 The rsyncd.conf file controls authentication, access, logging and
14 available modules.
15
16 manpagesection(FILE FORMAT)
17
18 The file consists of modules and parameters. A module begins with the
19 name of the module in square brackets and continues until the next
20 module begins. Modules contain parameters of the form "name = value".
21
22 The file is line-based -- that is, each newline-terminated line represents
23 either a comment, a module name or a parameter.
24
25 Only the first equals sign in a parameter is significant. Whitespace before
26 or after the first equals sign is discarded. Leading, trailing and internal
27 whitespace in module and parameter names is irrelevant. Leading and
28 trailing whitespace in a parameter value is discarded. Internal whitespace
29 within a parameter value is retained verbatim.
30
31 Any line bf(beginning) with a hash (#) is ignored, as are lines containing
32 only whitespace. (If a hash occurs after anything other than leading
33 whitespace, it is considered a part of the line's content.)
34
35 Any line ending in a \ is "continued" on the next line in the
36 customary UNIX fashion.
37
38 The values following the equals sign in parameters are all either a string
39 (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or
40 true/false. Case is not significant in boolean values, but is preserved
41 in string values.
42
43 manpagesection(LAUNCHING THE RSYNC DAEMON)
44
45 The rsync daemon is launched by specifying the bf(--daemon) option to
46 rsync.
47
48 The daemon must run with root privileges if you wish to use chroot, to
49 bind to a port numbered under 1024 (as is the default 873), or to set
50 file ownership.  Otherwise, it must just have permission to read and
51 write the appropriate data, log, and lock files.
52
53 You can launch it either via inetd, as a stand-alone daemon, or from
54 an rsync client via a remote shell.  If run as a stand-alone daemon then
55 just run the command "bf(rsync --daemon)" from a suitable startup script.
56
57 When run via inetd you should add a line like this to /etc/services:
58
59 verb(  rsync           873/tcp)
60
61 and a single line something like this to /etc/inetd.conf:
62
63 verb(  rsync   stream  tcp     nowait  root   /usr/bin/rsync rsyncd --daemon)
64
65 Replace "/usr/bin/rsync" with the path to where you have rsync installed on
66 your system.  You will then need to send inetd a HUP signal to tell it to
67 reread its config file.
68
69 Note that you should bf(not) send the rsync daemon a HUP signal to force
70 it to reread the tt(rsyncd.conf) file. The file is re-read on each client
71 connection.
72
73 manpagesection(GLOBAL PARAMETERS)
74
75 The first parameters in the file (before a [module] header) are the
76 global parameters.
77 Rsync also allows for the use of a "[global]" module name to indicate the
78 start of one or more global-parameter sections (the name must be lower case).
79
80 You may also include any module parameters in the global part of the
81 config file in which case the supplied value will override the
82 default for that parameter.
83
84 You may use references to environment variables in the values of parameters.
85 String parameters will have %VAR% references expanded as late as possible (when
86 the string is used in the program), allowing for the use of variables that
87 rsync sets at connection time, such as RSYNC_USER_NAME.  Non-string parameters
88 (such as true/false settings) are expanded when read from the config file.  If
89 a variable does not exist in the environment, or if a sequence of characters is
90 not a valid reference (such as an un-paired percent sign), the raw characters
91 are passed through unchanged.  This helps with backward compatibility and
92 safety (e.g. expanding a non-existent %VAR% to an empty string in a path could
93 result in a very unsafe path).  The safest way to insert a literal % into a
94 value is to use %%.
95
96 description(
97
98 dit(bf(motd file)) This parameter allows you to specify a
99 "message of the day" to display to clients on each connect. This
100 usually contains site information and any legal notices. The default
101 is no motd file.
102 This can be overridden by the bf(--dparam=motdfile=FILE)
103 command-line option when starting the daemon.
104
105 dit(bf(pid file)) This parameter tells the rsync daemon to write
106 its process ID to that file.  If the file already exists, the rsync
107 daemon will abort rather than overwrite the file.
108 This can be overridden by the bf(--dparam=pidfile=FILE)
109 command-line option when starting the daemon.
110
111 dit(bf(port)) You can override the default port the daemon will listen on
112 by specifying this value (defaults to 873).  This is ignored if the daemon
113 is being run by inetd, and is superseded by the bf(--port) command-line option.
114
115 dit(bf(address)) You can override the default IP address the daemon
116 will listen on by specifying this value.  This is ignored if the daemon is
117 being run by inetd, and is superseded by the bf(--address) command-line option.
118
119 dit(bf(socket options)) This parameter can provide endless fun for people
120 who like to tune their systems to the utmost degree. You can set all
121 sorts of socket options which may make transfers faster (or
122 slower!). Read the man page for the code(setsockopt()) system call for
123 details on some of the options you may be able to set. By default no
124 special socket options are set.  These settings can also be specified
125 via the bf(--sockopts) command-line option.
126
127 dit(bf(listen backlog)) You can override the default backlog value when the
128 daemon listens for connections.  It defaults to 5.
129
130 )
131
132 manpagesection(MODULE PARAMETERS)
133
134 After the global parameters you should define a number of modules, each
135 module exports a directory tree as a symbolic name. Modules are
136 exported by specifying a module name in square brackets [module]
137 followed by the parameters for that module.
138 The module name cannot contain a slash or a closing square bracket.  If the
139 name contains whitespace, each internal sequence of whitespace will be
140 changed into a single space, while leading or trailing whitespace will be
141 discarded.
142 Also, the name cannot be "global" as that exact name indicates that
143 global parameters follow (see above).
144
145 As with GLOBAL PARAMETERS, you may use references to environment variables in
146 the values of parameters.  See the GLOBAL PARAMETERS section for more details.
147
148 description(
149
150 dit(bf(comment)) This parameter specifies a description string
151 that is displayed next to the module name when clients obtain a list
152 of available modules. The default is no comment.
153
154 dit(bf(path)) This parameter specifies the directory in the daemon's
155 filesystem to make available in this module.  You must specify this parameter
156 for each module in tt(rsyncd.conf).
157
158 You may base the path's value off of an environment variable by surrounding
159 the variable name with percent signs.  You can even reference a variable
160 that is set by rsync when the user connects.
161 For example, this would use the authorizing user's name in the path:
162
163 verb(    path = /home/%RSYNC_USER_NAME% )
164
165 It is fine if the path includes internal spaces -- they will be retained
166 verbatim (which means that you shouldn't try to escape them).  If your final
167 directory has a trailing space (and this is somehow not something you wish to
168 fix), append a trailing slash to the path to avoid losing the trailing
169 whitespace.
170
171 dit(bf(use chroot)) If "use chroot" is true, the rsync daemon will chroot
172 to the "path" before starting the file transfer with the client.  This has
173 the advantage of extra protection against possible implementation security
174 holes, but it has the disadvantages of requiring super-user privileges,
175 of not being able to follow symbolic links that are either absolute or outside
176 of the new root path, and of complicating the preservation of users and groups
177 by name (see below).
178
179 As an additional safety feature, you can specify a dot-dir in the module's
180 "path" to indicate the point where the chroot should occur.  This allows rsync
181 to run in a chroot with a non-"/" path for the top of the transfer hierarchy.
182 Doing this guards against unintended library loading (since those absolute
183 paths will not be inside the transfer hierarchy unless you have used an unwise
184 pathname), and lets you setup libraries for the chroot that are outside of the
185 transfer.  For example, specifying "/var/rsync/./module1" will chroot to the
186 "/var/rsync" directory and set the inside-chroot path to "/module1".  If you
187 had omitted the dot-dir, the chroot would have used the whole path, and the
188 inside-chroot path would have been "/".
189
190 When both "use chroot" and "daemon chroot" are false, OR the inside-chroot path
191 of "use chroot" is not "/", rsync will: (1) munge symlinks by
192 default for security reasons (see "munge symlinks" for a way to turn this
193 off, but only if you trust your users), (2) substitute leading slashes in
194 absolute paths with the module's path (so that options such as
195 bf(--backup-dir), bf(--compare-dest), etc. interpret an absolute path as
196 rooted in the module's "path" dir), and (3) trim ".." path elements from
197 args if rsync believes they would escape the module hierarchy.
198 The default for "use chroot" is true, and is the safer choice (especially
199 if the module is not read-only).
200
201 When this parameter is enabled, the "numeric-ids" option will also default to
202 being enabled (disabling name lookups).  See below for what a chroot needs in
203 order for name lookups to succeed.
204
205 If you copy library resources into the module's chroot area, you
206 should protect them through your OS's normal user/group or ACL settings (to
207 prevent the rsync module's user from being able to change them), and then
208 hide them from the user's view via "exclude" (see how in the discussion of
209 that parameter).  At that point it will be safe to enable the mapping of users
210 and groups by name using the "numeric ids" daemon parameter (see below).
211
212 Note also that you are free to setup custom user/group information in the
213 chroot area that is different from your normal system.  For example, you
214 could abbreviate the list of users and groups.
215
216 dit(bf(daemon chroot)) This parameter specifies a path to which the daemon will
217 chroot before beginning communication with clients. Module paths (and any "use
218 chroot" settings) will then be related to this one. This lets you choose if you
219 want the whole daemon to be chrooted (with this setting), just the transfers to
220 be chrooted (with "use chroot"), or both.  Keep in mind that the "daemon chroot"
221 area may need various OS/lib/etc files installed to allow the daemon to function.
222 By default the daemon runs without any chrooting.
223
224 dit(bf(numeric ids)) Enabling this parameter disables the mapping
225 of users and groups by name for the current daemon module.  This prevents
226 the daemon from trying to load any user/group-related files or libraries.
227 This enabling makes the transfer behave as if the client had passed
228 the bf(--numeric-ids) command-line option.  By default, this parameter is
229 enabled for chroot modules and disabled for non-chroot modules.
230 Also keep in mind that uid/gid preservation requires the module to be
231 running as root (see "uid") or for "fake super" to be configured.
232
233 A chroot-enabled module should not have this parameter enabled unless you've
234 taken steps to ensure that the module has the necessary resources it needs
235 to translate names, and that it is not possible for a user to change those
236 resources.  That includes being the code being able to call functions like
237 code(getpwuid()), code(getgrgid()), code(getpwname()), and code(getgrnam()).
238 You should test what libraries and config files are required for your OS
239 and get those setup before starting to test name mapping in rsync.
240
241 dit(bf(munge symlinks)) This parameter tells rsync to modify
242 all symlinks in the same way as the (non-daemon-affecting)
243 bf(--munge-links) command-line option (using a method described below).
244 This should help protect your files from user trickery when
245 your daemon module is writable.  The default is disabled when "use chroot"
246 is on with an inside-chroot path of "/", OR if "daemon chroot" is on,
247 otherwise it is enabled.
248
249 If you disable this parameter on a daemon that is not read-only, there
250 are tricks that a user can play with uploaded symlinks to access
251 daemon-excluded items (if your module has any), and, if "use chroot"
252 is off, rsync can even be tricked into showing or changing data that
253 is outside the module's path (as access-permissions allow).
254
255 The way rsync disables the use of symlinks is to prefix each one with
256 the string "/rsyncd-munged/".  This prevents the links from being used
257 as long as that directory does not exist.  When this parameter is enabled,
258 rsync will refuse to run if that path is a directory or a symlink to
259 a directory.  When using the "munge symlinks" parameter in a chroot area
260 that has an inside-chroot path of "/", you should add "/rsyncd-munged/"
261 to the exclude setting for the module so that
262 a user can't try to create it.
263
264 Note:  rsync makes no attempt to verify that any pre-existing symlinks in
265 the module's hierarchy are as safe as you want them to be (unless, of
266 course, it just copied in the whole hierarchy).  If you setup an rsync
267 daemon on a new area or locally add symlinks, you can manually protect your
268 symlinks from being abused by prefixing "/rsyncd-munged/" to the start of
269 every symlink's value.  There is a perl script in the support directory
270 of the source code named "munge-symlinks" that can be used to add or remove
271 this prefix from your symlinks.
272
273 When this parameter is disabled on a writable module and "use chroot" is off
274 (or the inside-chroot path is not "/"),
275 incoming symlinks will be modified to drop a leading slash and to remove ".."
276 path elements that rsync believes will allow a symlink to escape the module's
277 hierarchy.  There are tricky ways to work around this, though, so you had
278 better trust your users if you choose this combination of parameters.
279
280 dit(bf(charset)) This specifies the name of the character set in which the
281 module's filenames are stored.  If the client uses an bf(--iconv) option,
282 the daemon will use the value of the "charset" parameter regardless of the
283 character set the client actually passed.  This allows the daemon to
284 support charset conversion in a chroot module without extra files in the
285 chroot area, and also ensures that name-translation is done in a consistent
286 manner.  If the "charset" parameter is not set, the bf(--iconv) option is
287 refused, just as if "iconv" had been specified via "refuse options".
288
289 If you wish to force users to always use bf(--iconv) for a particular
290 module, add "no-iconv" to the "refuse options" parameter.  Keep in mind
291 that this will restrict access to your module to very new rsync clients.
292
293 dit(bf(max connections)) This parameter allows you to
294 specify the maximum number of simultaneous connections you will allow.
295 Any clients connecting when the maximum has been reached will receive a
296 message telling them to try later.  The default is 0, which means no limit.
297 A negative value disables the module.
298 See also the "lock file" parameter.
299
300 dit(bf(log file)) When the "log file" parameter is set to a non-empty
301 string, the rsync daemon will log messages to the indicated file rather
302 than using syslog. This is particularly useful on systems (such as AIX)
303 where code(syslog()) doesn't work for chrooted programs.  The file is
304 opened before code(chroot()) is called, allowing it to be placed outside
305 the transfer.  If this value is set on a per-module basis instead of
306 globally, the global log will still contain any authorization failures
307 or config-file error messages.
308
309 If the daemon fails to open the specified file, it will fall back to
310 using syslog and output an error about the failure.  (Note that the
311 failure to open the specified log file used to be a fatal error.)
312
313 This setting can be overridden by using the bf(--log-file=FILE) or
314 bf(--dparam=logfile=FILE) command-line options.  The former overrides
315 all the log-file parameters of the daemon and all module settings.
316 The latter sets the daemon's log file and the default for all the
317 modules, which still allows modules to override the default setting.
318
319 dit(bf(syslog facility)) This parameter allows you to
320 specify the syslog facility name to use when logging messages from the
321 rsync daemon. You may use any standard syslog facility name which is
322 defined on your system. Common names are auth, authpriv, cron, daemon,
323 ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0,
324 local1, local2, local3, local4, local5, local6 and local7. The default
325 is daemon.  This setting has no effect if the "log file" setting is a
326 non-empty string (either set in the per-modules settings, or inherited
327 from the global settings).
328
329 dit(bf(syslog tag)) This parameter allows you to specify the syslog
330 tag to use when logging messages from the rsync daemon. The default is
331 "rsyncd".  This setting has no effect if the "log file" setting is a
332 non-empty string (either set in the per-modules settings, or inherited
333 from the global settings).
334
335 For example, if you wanted each authenticated user's name to be
336 included in the syslog tag, you could do something like this:
337
338 verb(    syslog tag = rsyncd.%RSYNC_USER_NAME%)
339
340 dit(bf(max verbosity)) This parameter allows you to control
341 the maximum amount of verbose information that you'll allow the daemon to
342 generate (since the information goes into the log file). The default is 1,
343 which allows the client to request one level of verbosity.
344
345 This also affects the user's ability to request higher levels of bf(--info) and
346 bf(--debug) logging.  If the max value is 2, then no info and/or debug value
347 that is higher than what would be set by bf(-vv) will be honored by the daemon
348 in its logging.  To see how high of a verbosity level you need to accept for a
349 particular info/debug level, refer to "rsync --info=help" and "rsync --debug=help".
350 For instance, it takes max-verbosity 4 to be able to output debug TIME2 and FLIST3.
351
352 dit(bf(lock file)) This parameter specifies the file to use to
353 support the "max connections" parameter. The rsync daemon uses record
354 locking on this file to ensure that the max connections limit is not
355 exceeded for the modules sharing the lock file.
356 The default is tt(/var/run/rsyncd.lock).
357
358 dit(bf(read only)) This parameter determines whether clients
359 will be able to upload files or not. If "read only" is true then any
360 attempted uploads will fail. If "read only" is false then uploads will
361 be possible if file permissions on the daemon side allow them. The default
362 is for all modules to be read only.
363
364 Note that "auth users" can override this setting on a per-user basis.
365
366 dit(bf(write only)) This parameter determines whether clients
367 will be able to download files or not. If "write only" is true then any
368 attempted downloads will fail. If "write only" is false then downloads
369 will be possible if file permissions on the daemon side allow them.  The
370 default is for this parameter to be disabled.
371
372 Helpful hint: you probably want to specify "refuse options = delete" for a
373 write-only module.
374
375 )
376 description(
377
378 dit(bf(list)) This parameter determines whether this module is
379 listed when the client asks for a listing of available modules.  In addition,
380 if this is false, the daemon will pretend the module does not exist
381 when a client denied by "hosts allow" or "hosts deny" attempts to access it.
382 Realize that if "reverse lookup" is disabled globally but enabled for the
383 module, the resulting reverse lookup to a potentially client-controlled DNS
384 server may still reveal to the client that it hit an existing module.
385 The default is for modules to be listable.
386
387 dit(bf(uid)) This parameter specifies the user name or user ID that
388 file transfers to and from that module should take place as when the daemon
389 was run as root. In combination with the "gid" parameter this determines what
390 file permissions are available. The default when run by a super-user is to
391 switch to the system's "nobody" user.  The default for a non-super-user is to
392 not try to change the user.  See also the "gid" parameter.
393
394 The RSYNC_USER_NAME environment variable may be used to request that rsync run
395 as the authorizing user.  For example, if you want a rsync to run as the same
396 user that was received for the rsync authentication, this setup is useful:
397
398 verb(    uid = %RSYNC_USER_NAME%
399     gid = * )
400
401 dit(bf(gid)) This parameter specifies one or more group names/IDs that will be
402 used when accessing the module.  The first one will be the default group, and
403 any extra ones be set as supplemental groups.  You may also specify a "*" as
404 the first gid in the list, which will be replaced by all the normal groups for
405 the transfer's user (see "uid").  The default when run by a super-user is to
406 switch to your OS's "nobody" (or perhaps "nogroup") group with no other
407 supplementary groups.  The default for a non-super-user is to not change any
408 group attributes (and indeed, your OS may not allow a non-super-user to try to
409 change their group settings).
410
411 dit(bf(daemon uid)) This parameter specifies a uid under which the daemon will
412 run. The daemon usually runs as user root, and when this is left unset the user
413 is left unchanged. See also the "uid" parameter.
414
415 dit(bf(daemon gid)) This parameter specifies a gid under which the daemon will
416 run. The daemon usually runs as group root, and when this is left unset, the
417 group is left unchanged. See also the "gid" parameter.
418
419 dit(bf(fake super)) Setting "fake super = yes" for a module causes the
420 daemon side to behave as if the bf(--fake-super) command-line option had
421 been specified.  This allows the full attributes of a file to be stored
422 without having to have the daemon actually running as root.
423
424 dit(bf(filter)) The daemon has its own filter chain that determines what files
425 it will let the client access.  This chain is not sent to the client and is
426 independent of any filters the client may have specified.  Files excluded by
427 the daemon filter chain (bf(daemon-excluded) files) are treated as non-existent
428 if the client tries to pull them, are skipped with an error message if the
429 client tries to push them (triggering exit code 23), and are never deleted from
430 the module.  You can use daemon filters to prevent clients from downloading or
431 tampering with private administrative files, such as files you may add to
432 support uid/gid name translations.
433
434 The daemon filter chain is built from the "filter", "include from", "include",
435 "exclude from", and "exclude" parameters, in that order of priority.  Anchored
436 patterns are anchored at the root of the module.  To prevent access to an
437 entire subtree, for example, "/secret", you em(must) exclude everything in the
438 subtree; the easiest way to do this is with a triple-star pattern like
439 "/secret/***".
440
441 The "filter" parameter takes a space-separated list of daemon filter rules,
442 though it is smart enough to know not to split a token at an internal space in
443 a rule (e.g. "- /foo  - /bar" is parsed as two rules).  You may specify one or
444 more merge-file rules using the normal syntax.  Only one "filter" parameter can
445 apply to a given module in the config file, so put all the rules you want in a
446 single parameter.  Note that per-directory merge-file rules do not provide as
447 much protection as global rules, but they can be used to make bf(--delete) work
448 better during a client download operation if the per-dir merge files are
449 included in the transfer and the client requests that they be used.
450
451 dit(bf(exclude)) This parameter takes a space-separated list of daemon
452 exclude patterns.  As with the client bf(--exclude) option, patterns can be
453 qualified with "- " or "+ " to explicitly indicate exclude/include.  Only one
454 "exclude" parameter can apply to a given module.  See the "filter" parameter
455 for a description of how excluded files affect the daemon.
456
457 dit(bf(include)) Use an "include" to override the effects of the "exclude"
458 parameter.  Only one "include" parameter can apply to a given module.  See the
459 "filter" parameter for a description of how excluded files affect the daemon.
460
461 dit(bf(exclude from)) This parameter specifies the name of a file
462 on the daemon that contains daemon exclude patterns, one per line.  Only one
463 "exclude from" parameter can apply to a given module; if you have multiple
464 exclude-from files, you can specify them as a merge file in the "filter"
465 parameter.  See the "filter" parameter for a description of how excluded files
466 affect the daemon.
467
468 dit(bf(include from)) Analogue of "exclude from" for a file of daemon include
469 patterns.  Only one "include from" parameter can apply to a given module.  See
470 the "filter" parameter for a description of how excluded files affect the
471 daemon.
472
473 dit(bf(incoming chmod)) This parameter allows you to specify a set of
474 comma-separated chmod strings that will affect the permissions of all
475 incoming files (files that are being received by the daemon).  These
476 changes happen after all other permission calculations, and this will
477 even override destination-default and/or existing permissions when the
478 client does not specify bf(--perms).
479 See the description of the bf(--chmod) rsync option and the bf(chmod)(1)
480 manpage for information on the format of this string.
481
482 dit(bf(outgoing chmod)) This parameter allows you to specify a set of
483 comma-separated chmod strings that will affect the permissions of all
484 outgoing files (files that are being sent out from the daemon).  These
485 changes happen first, making the sent permissions appear to be different
486 than those stored in the filesystem itself.  For instance, you could
487 disable group write permissions on the server while having it appear to
488 be on to the clients.
489 See the description of the bf(--chmod) rsync option and the bf(chmod)(1)
490 manpage for information on the format of this string.
491
492 dit(bf(auth users)) This parameter specifies a comma and/or space-separated
493 list of authorization rules.  In its simplest form, you list the usernames
494 that will be allowed to connect to
495 this module. The usernames do not need to exist on the local
496 system. The rules may contain shell wildcard characters that will be matched
497 against the username provided by the client for authentication. If
498 "auth users" is set then the client will be challenged to supply a
499 username and password to connect to the module. A challenge response
500 authentication protocol is used for this exchange. The plain text
501 usernames and passwords are stored in the file specified by the
502 "secrets file" parameter. The default is for all users to be able to
503 connect without a password (this is called "anonymous rsync").
504
505 In addition to username matching, you can specify groupname matching via a '@'
506 prefix.  When using groupname matching, the authenticating username must be a
507 real user on the system, or it will be assumed to be a member of no groups.
508 For example, specifying "@rsync" will match the authenticating user if the
509 named user is a member of the rsync group.
510
511 Finally, options may be specified after a colon (:).  The options allow you to
512 "deny" a user or a group, set the access to "ro" (read-only), or set the access
513 to "rw" (read/write).  Setting an auth-rule-specific ro/rw setting overrides
514 the module's "read only" setting.
515
516 Be sure to put the rules in the order you want them to be matched, because the
517 checking stops at the first matching user or group, and that is the only auth
518 that is checked.  For example:
519
520 verb(  auth users = joe:deny @guest:deny admin:rw @rsync:ro susan joe sam )
521
522 In the above rule, user joe will be denied access no matter what.  Any user
523 that is in the group "guest" is also denied access.  The user "admin" gets
524 access in read/write mode, but only if the admin user is not in group "guest"
525 (because the admin user-matching rule would never be reached if the user is in
526 group "guest").  Any other user who is in group "rsync" will get read-only
527 access.  Finally, users susan, joe, and sam get the ro/rw setting of the
528 module, but only if the user didn't match an earlier group-matching rule.
529
530 If you need to specify a user or group name with a space in it, start your list
531 with a comma to indicate that the list should only be split on commas (though
532 leading and trailing whitespace will also be removed, and empty entries are
533 just ignored).  For example:
534
535 verb(  auth users = , joe:deny, @Some Group:deny, admin:rw, @RO Group:ro )
536
537 See the description of the secrets file for how you can have per-user passwords
538 as well as per-group passwords.  It also explains how a user can authenticate
539 using their user password or (when applicable) a group password, depending on
540 what rule is being authenticated.
541
542 See also the section entitled "USING RSYNC-DAEMON FEATURES VIA A REMOTE
543 SHELL CONNECTION" in bf(rsync)(1) for information on how handle an
544 rsyncd.conf-level username that differs from the remote-shell-level
545 username when using a remote shell to connect to an rsync daemon.
546
547 dit(bf(secrets file)) This parameter specifies the name of a file that contains
548 the username:password and/or @groupname:password pairs used for authenticating
549 this module. This file is only consulted if the "auth users" parameter is
550 specified.  The file is line-based and contains one name:password pair per
551 line.  Any line has a hash (#) as the very first character on the line is
552 considered a comment and is skipped.  The passwords can contain any characters
553 but be warned that many operating systems limit the length of passwords that
554 can be typed at the client end, so you may find that passwords longer than 8
555 characters don't work.
556
557 The use of group-specific lines are only relevant when the module is being
558 authorized using a matching "@groupname" rule.  When that happens, the user
559 can be authorized via either their "username:password" line or the
560 "@groupname:password" line for the group that triggered the authentication.
561
562 It is up to you what kind of password entries you want to include, either
563 users, groups, or both.  The use of group rules in "auth users" does not
564 require that you specify a group password if you do not want to use shared
565 passwords.
566
567 There is no default for the "secrets file" parameter, you must choose a name
568 (such as tt(/etc/rsyncd.secrets)).  The file must normally not be readable
569 by "other"; see "strict modes".  If the file is not found or is rejected, no
570 logins for a "user auth" module will be possible.
571
572 dit(bf(strict modes)) This parameter determines whether or not
573 the permissions on the secrets file will be checked.  If "strict modes" is
574 true, then the secrets file must not be readable by any user ID other
575 than the one that the rsync daemon is running under.  If "strict modes" is
576 false, the check is not performed.  The default is true.  This parameter
577 was added to accommodate rsync running on the Windows operating system.
578
579 )
580 description(
581
582 dit(bf(hosts allow)) This parameter allows you to specify a list of comma-
583 and/or whitespace-separated patterns that are matched against a connecting
584 client's hostname and IP address.  If none of the patterns match, then the
585 connection is rejected.
586
587 Each pattern can be in one of five forms:
588
589 quote(itemization(
590   it() a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address
591   of the form a:b:c::d:e:f. In this case the incoming machine's IP address
592   must match exactly.
593   it() an address/mask in the form ipaddr/n where ipaddr is the IP address
594   and n is the number of one bits in the netmask.  All IP addresses which
595   match the masked IP address will be allowed in.
596   it() an address/mask in the form ipaddr/maskaddr where ipaddr is the
597   IP address and maskaddr is the netmask in dotted decimal notation for IPv4,
598   or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP
599   addresses which match the masked IP address will be allowed in.
600   it() a hostname pattern using wildcards. If the hostname of the connecting IP
601   (as determined by a reverse lookup) matches the wildcarded name (using the
602   same rules as normal unix filename matching), the client is allowed in.  This
603   only works if "reverse lookup" is enabled (the default).
604   it() a hostname. A plain hostname is matched against the reverse DNS of the
605   connecting IP (if "reverse lookup" is enabled), and/or the IP of the given
606   hostname is matched against the connecting IP (if "forward lookup" is
607   enabled, as it is by default).  Any match will be allowed in.
608 ))
609
610 Note IPv6 link-local addresses can have a scope in the address specification:
611
612 quote(
613 tt(    fe80::1%link1)nl()
614 tt(    fe80::%link1/64)nl()
615 tt(    fe80::%link1/ffff:ffff:ffff:ffff::)nl()
616 )
617
618 You can also combine "hosts allow" with a separate "hosts deny"
619 parameter. If both parameters are specified then the "hosts allow" parameter is
620 checked first and a match results in the client being able to
621 connect. The "hosts deny" parameter is then checked and a match means
622 that the host is rejected. If the host does not match either the
623 "hosts allow" or the "hosts deny" patterns then it is allowed to
624 connect.
625
626 The default is no "hosts allow" parameter, which means all hosts can connect.
627
628 dit(bf(hosts deny)) This parameter allows you to specify a list of comma-
629 and/or whitespace-separated patterns that are matched against a connecting
630 clients hostname and IP address. If the pattern matches then the connection is
631 rejected. See the "hosts allow" parameter for more information.
632
633 The default is no "hosts deny" parameter, which means all hosts can connect.
634
635 dit(bf(reverse lookup)) Controls whether the daemon performs a reverse lookup
636 on the client's IP address to determine its hostname, which is used for
637 "hosts allow"/"hosts deny" checks and the "%h" log escape.  This is enabled by
638 default, but you may wish to disable it to save time if you know the lookup will
639 not return a useful result, in which case the daemon will use the name
640 "UNDETERMINED" instead.
641
642 If this parameter is enabled globally (even by default), rsync performs the
643 lookup as soon as a client connects, so disabling it for a module will not
644 avoid the lookup.  Thus, you probably want to disable it globally and then
645 enable it for modules that need the information.
646
647 dit(bf(forward lookup)) Controls whether the daemon performs a forward lookup
648 on any hostname specified in an hosts allow/deny setting.  By default this is
649 enabled, allowing the use of an explicit hostname that would not be returned
650 by reverse DNS of the connecting IP.
651
652 dit(bf(ignore errors)) This parameter tells rsyncd to
653 ignore I/O errors on the daemon when deciding whether to run the delete
654 phase of the transfer. Normally rsync skips the bf(--delete) step if any
655 I/O errors have occurred in order to prevent disastrous deletion due
656 to a temporary resource shortage or other I/O error. In some cases this
657 test is counter productive so you can use this parameter to turn off this
658 behavior.
659
660 dit(bf(ignore nonreadable)) This tells the rsync daemon to completely
661 ignore files that are not readable by the user. This is useful for
662 public archives that may have some non-readable files among the
663 directories, and the sysadmin doesn't want those files to be seen at all.
664
665 dit(bf(transfer logging)) This parameter enables per-file
666 logging of downloads and uploads in a format somewhat similar to that
667 used by ftp daemons.  The daemon always logs the transfer at the end, so
668 if a transfer is aborted, no mention will be made in the log file.
669
670 If you want to customize the log lines, see the "log format" parameter.
671
672 dit(bf(log format)) This parameter allows you to specify the
673 format used for logging file transfers when transfer logging is enabled.
674 The format is a text string containing embedded single-character escape
675 sequences prefixed with a percent (%) character.  An optional numeric
676 field width may also be specified between the percent and the escape
677 letter (e.g. "bf(%-50n %8l %07p)").
678 In addition, one or more apostrophes may be specified prior to a numerical
679 escape to indicate that the numerical value should be made more human-readable.
680 The 3 supported levels are the same as for the bf(--human-readable)
681 command-line option, though the default is for human-readability to be off.
682 Each added apostrophe increases the level (e.g. "bf(%''l %'b %f)").
683
684 The default log format is "%o %h [%a] %m (%u) %f %l", and a "%t [%p] "
685 is always prefixed when using the "log file" parameter.
686 (A perl script that will summarize this default log format is included
687 in the rsync source code distribution in the "support" subdirectory:
688 rsyncstats.)
689
690 The single-character escapes that are understood are as follows:
691
692 quote(itemization(
693   it() %a the remote IP address (only available for a daemon)
694   it() %b the number of bytes actually transferred
695   it() %B the permission bits of the file (e.g. rwxrwxrwt)
696   it() %c the total size of the block checksums received for the basis file (only when sending)
697   it() %C the full-file checksum if it is known for the file. For older rsync protocols/versions, the checksum was salted, and is thus not a useful value (and is not displayed when that is the case). For the checksum to output for a file, either the bf(--checksum) option must be in-effect or the file must have been transferred without a salted checksum being used. See the bf(--checksum-choice) option for a way to choose the algorithm.
698   it() %f the filename (long form on sender; no trailing "/")
699   it() %G the gid of the file (decimal) or "DEFAULT"
700   it() %h the remote host name (only available for a daemon)
701   it() %i an itemized list of what is being updated
702   it() %l the length of the file in bytes
703   it() %L the string " -> SYMLINK", " => HARDLINK", or "" (where bf(SYMLINK) or bf(HARDLINK) is a filename)
704   it() %m the module name
705   it() %M the last-modified time of the file
706   it() %n the filename (short form; trailing "/" on dir)
707   it() %o the operation, which is "send", "recv", or "del." (the latter includes the trailing period)
708   it() %p the process ID of this rsync session
709   it() %P the module path
710   it() %t the current date time
711   it() %u the authenticated username or an empty string
712   it() %U the uid of the file (decimal)
713 ))
714
715 For a list of what the characters mean that are output by "%i", see the
716 bf(--itemize-changes) option in the rsync manpage.
717
718 Note that some of the logged output changes when talking with older
719 rsync versions.  For instance, deleted files were only output as verbose
720 messages prior to rsync 2.6.4.
721
722 )
723 description(
724
725 dit(bf(timeout)) This parameter allows you to override the
726 clients choice for I/O timeout for this module. Using this parameter you
727 can ensure that rsync won't wait on a dead client forever. The timeout
728 is specified in seconds. A value of zero means no timeout and is the
729 default. A good choice for anonymous rsync daemons may be 600 (giving
730 a 10 minute timeout).
731
732 dit(bf(refuse options)) This parameter allows you to
733 specify a space-separated list of rsync command line options that will
734 be refused by your rsync daemon.
735 You may specify the full option name, its one-letter abbreviation, or a
736 wild-card string that matches multiple options.
737 For example, this would refuse bf(--checksum) (bf(-c)) and all the various
738 delete options:
739
740 quote(tt(    refuse options = c delete))
741
742 The reason the above refuses all delete options is that the options imply
743 bf(--delete), and implied options are refused just like explicit options.
744 As an additional safety feature, the refusal of "delete" also refuses
745 bf(remove-source-files) when the daemon is the sender; if you want the latter
746 without the former, instead refuse "delete-*" -- that refuses all the
747 delete modes without affecting bf(--remove-source-files).
748
749 When an option is refused, the daemon prints an error message and exits.
750 To prevent all compression when serving files,
751 you can use "dont compress = *" (see below)
752 instead of "refuse options = compress" to avoid returning an error to a
753 client that requests compression.
754
755 dit(bf(dont compress)) This parameter allows you to select
756 filenames based on wildcard patterns that should not be compressed
757 when pulling files from the daemon (no analogous parameter exists to
758 govern the pushing of files to a daemon).
759 Compression is expensive in terms of CPU usage, so it
760 is usually good to not try to compress files that won't compress well,
761 such as already compressed files.
762
763 The "dont compress" parameter takes a space-separated list of
764 case-insensitive wildcard patterns. Any source filename matching one
765 of the patterns will not be compressed during transfer.
766
767 See the bf(--skip-compress) parameter in the bf(rsync)(1) manpage for the list
768 of file suffixes that are not compressed by default.  Specifying a value
769 for the "dont compress" parameter changes the default when the daemon is
770 the sender.
771
772 )
773 description(
774
775 dit(bf(pre-xfer exec), bf(post-xfer exec)) You may specify a command to be run
776 before and/or after the transfer.  If the bf(pre-xfer exec) command fails, the
777 transfer is aborted before it begins.  Any output from the script on stdout (up
778 to several KB) will be displayed to the user when aborting, but is NOT
779 displayed if the script returns success.  Any output from the script on stderr
780 goes to the daemon's stderr, which is typically discarded (though see
781 --no-detatch option for a way to see the stderr output, which can assist with
782 debugging).
783
784 The following environment variables will be set, though some are
785 specific to the pre-xfer or the post-xfer environment:
786
787 quote(itemization(
788   it() bf(RSYNC_MODULE_NAME): The name of the module being accessed.
789   it() bf(RSYNC_MODULE_PATH): The path configured for the module.
790   it() bf(RSYNC_HOST_ADDR): The accessing host's IP address.
791   it() bf(RSYNC_HOST_NAME): The accessing host's name.
792   it() bf(RSYNC_USER_NAME): The accessing user's name (empty if no user).
793   it() bf(RSYNC_PID): A unique number for this transfer.
794   it() bf(RSYNC_REQUEST): (pre-xfer only) The module/path info specified
795   by the user.  Note that the user can specify multiple source files,
796   so the request can be something like "mod/path1 mod/path2", etc.
797   it() bf(RSYNC_ARG#): (pre-xfer only) The pre-request arguments are set
798   in these numbered values. RSYNC_ARG0 is always "rsyncd", followed by
799   the options that were used in RSYNC_ARG1, and so on.  There will be a
800   value of "." indicating that the options are done and the path args
801   are beginning -- these contain similar information to RSYNC_REQUEST,
802   but with values separated and the module name stripped off.
803   it() bf(RSYNC_EXIT_STATUS): (post-xfer only) the server side's exit value.
804   This will be 0 for a successful run, a positive value for an error that the
805   server generated, or a -1 if rsync failed to exit properly.  Note that an
806   error that occurs on the client side does not currently get sent to the
807   server side, so this is not the final exit status for the whole transfer.
808   it() bf(RSYNC_RAW_STATUS): (post-xfer only) the raw exit value from code(waitpid()).
809 ))
810
811 Even though the commands can be associated with a particular module, they
812 are run using the permissions of the user that started the daemon (not the
813 module's uid/gid setting) without any chroot restrictions.
814
815 These settings honor 2 environment variables: use RSYNC_SHELL to set a shell to
816 use when running the command (which otherwise uses your system() call's default
817 shell), and use RSYNC_NO_XFER_EXEC to disable both options completely.
818
819 )
820
821 manpagesection(CONFIG DIRECTIVES)
822
823 There are currently two config directives available that allow a config file to
824 incorporate the contents of other files:  bf(&include) and bf(&merge).  Both
825 allow a reference to either a file or a directory.  They differ in how
826 segregated the file's contents are considered to be.
827
828 The bf(&include) directive treats each file as more distinct, with each one
829 inheriting the defaults of the parent file, starting the parameter parsing
830 as globals/defaults, and leaving the defaults unchanged for the parsing of
831 the rest of the parent file.
832
833 The bf(&merge) directive, on the other hand, treats the file's contents as
834 if it were simply inserted in place of the directive, and thus it can set
835 parameters in a module started in another file, can affect the defaults for
836 other files, etc.
837
838 When an bf(&include) or bf(&merge) directive refers to a directory, it will read
839 in all the bf(*.conf) or bf(*.inc) files (respectively) that are contained inside
840 that directory (without any
841 recursive scanning), with the files sorted into alpha order.  So, if you have a
842 directory named "rsyncd.d" with the files "foo.conf", "bar.conf", and
843 "baz.conf" inside it, this directive:
844
845 verb(    &include /path/rsyncd.d )
846
847 would be the same as this set of directives:
848
849 verb(    &include /path/rsyncd.d/bar.conf
850     &include /path/rsyncd.d/baz.conf
851     &include /path/rsyncd.d/foo.conf )
852
853 except that it adjusts as files are added and removed from the directory.
854
855 The advantage of the bf(&include) directive is that you can define one or more
856 modules in a separate file without worrying about unintended side-effects
857 between the self-contained module files.
858
859 The advantage of the bf(&merge) directive is that you can load config snippets
860 that can be included into multiple module definitions, and you can also set
861 global values that will affect connections (such as bf(motd file)), or globals
862 that will affect other include files.
863
864 For example, this is a useful /etc/rsyncd.conf file:
865
866 verb(    port = 873
867     log file = /var/log/rsync.log
868     pid file = /var/lock/rsync.lock
869
870     &merge /etc/rsyncd.d
871     &include /etc/rsyncd.d )
872
873 This would merge any /etc/rsyncd.d/*.inc files (for global values that should
874 stay in effect), and then include any /etc/rsyncd.d/*.conf files (defining
875 modules without any global-value cross-talk).
876
877 manpagesection(AUTHENTICATION STRENGTH)
878
879 The authentication protocol used in rsync is a 128 bit MD4 based
880 challenge response system. This is fairly weak protection, though (with
881 at least one brute-force hash-finding algorithm publicly available), so
882 if you want really top-quality security, then I recommend that you run
883 rsync over ssh.  (Yes, a future version of rsync will switch over to a
884 stronger hashing method.)
885
886 Also note that the rsync daemon protocol does not currently provide any
887 encryption of the data that is transferred over the connection. Only
888 authentication is provided. Use ssh as the transport if you want
889 encryption.
890
891 Future versions of rsync may support SSL for better authentication and
892 encryption, but that is still being investigated.
893
894 manpagesection(EXAMPLES)
895
896 A simple rsyncd.conf file that allow anonymous rsync to a ftp area at
897 tt(/home/ftp) would be:
898
899 verb(
900 [ftp]
901         path = /home/ftp
902         comment = ftp export area
903 )
904
905 A more sophisticated example would be:
906
907 verb(
908 uid = nobody
909 gid = nobody
910 use chroot = yes
911 max connections = 4
912 syslog facility = local5
913 pid file = /var/run/rsyncd.pid
914
915 [ftp]
916         path = /var/ftp/./pub
917         comment = whole ftp area (approx 6.1 GB)
918
919 [sambaftp]
920         path = /var/ftp/./pub/samba
921         comment = Samba ftp area (approx 300 MB)
922
923 [rsyncftp]
924         path = /var/ftp/./pub/rsync
925         comment = rsync ftp area (approx 6 MB)
926
927 [sambawww]
928         path = /public_html/samba
929         comment = Samba WWW pages (approx 240 MB)
930
931 [cvs]
932         path = /data/cvs
933         comment = CVS repository (requires authentication)
934         auth users = tridge, susan
935         secrets file = /etc/rsyncd.secrets
936 )
937
938 The /etc/rsyncd.secrets file would look something like this:
939
940 quote(
941 tt(tridge:mypass)nl()
942 tt(susan:herpass)nl()
943 )
944
945 manpagefiles()
946
947 /etc/rsyncd.conf or rsyncd.conf
948
949 manpageseealso()
950
951 bf(rsync)(1)
952
953 manpagediagnostics()
954
955 manpagebugs()
956
957 Please report bugs! The rsync bug tracking system is online at
958 url(http://rsync.samba.org/)(http://rsync.samba.org/)
959
960 manpagesection(VERSION)
961
962 This man page is current for version 3.1.3 of rsync.
963
964 manpagesection(CREDITS)
965
966 rsync is distributed under the GNU General Public License.  See the file
967 COPYING for details.
968
969 The primary ftp site for rsync is
970 url(ftp://rsync.samba.org/pub/rsync)(ftp://rsync.samba.org/pub/rsync).
971
972 A WEB site is available at
973 url(http://rsync.samba.org/)(http://rsync.samba.org/)
974
975 We would be delighted to hear from you if you like this program.
976
977 This program uses the zlib compression library written by Jean-loup
978 Gailly and Mark Adler.
979
980 manpagesection(THANKS)
981
982 Thanks to Warren Stanley for his original idea and patch for the rsync
983 daemon. Thanks to Karsten Thygesen for his many suggestions and
984 documentation!
985
986 manpageauthor()
987
988 rsync was written by Andrew Tridgell and Paul Mackerras.
989 Many people have later contributed to it.
990
991 Mailing lists for support and development are available at
992 url(http://lists.samba.org)(lists.samba.org)