@@ -164,6 +164,16 @@ the values of parameters. See the GLOBAL PARAMETERS section for more details.
164
164
available in this module. You must specify this parameter for each module
165
165
in ` rsyncd.conf ` .
166
166
167
+ If the value contains a "/./" element then the path will be divided at that
168
+ point into a chroot dir and an inner-chroot subdir. If [ ` use chroot ` ] ( # )
169
+ is set to false, though, the extraneous dot dir is just cleaned out of the
170
+ path. An example of this idiom is:
171
+
172
+ > path = /var/rsync/./module1
173
+
174
+ This will (when chrooting) chroot to "/var/rsync" and set the inside-chroot
175
+ path to "/module1".
176
+
167
177
You may base the path's value off of an environment variable by surrounding
168
178
the variable name with percent signs. You can even reference a variable
169
179
that is set by rsync when the user connects. For example, this would use
@@ -187,29 +197,43 @@ the values of parameters. See the GLOBAL PARAMETERS section for more details.
187
197
path, and of complicating the preservation of users and groups by name (see
188
198
below).
189
199
190
- As an additional safety feature, you can specify a dot-dir in the module's
191
- "[ path] ( # ) " to indicate the point where the chroot should occur. This allows
192
- rsync to run in a chroot with a non-"/" path for the top of the transfer
193
- hierarchy. Doing this guards against unintended library loading (since
194
- those absolute paths will not be inside the transfer hierarchy unless you
195
- have used an unwise pathname), and lets you setup libraries for the chroot
196
- that are outside of the transfer. For example, specifying
197
- "/var/rsync/./module1" will chroot to the "/var/rsync" directory and set
198
- the inside-chroot path to "/module1". If you had omitted the dot-dir, the
199
- chroot would have used the whole path, and the inside-chroot path would
200
- have been "/".
201
-
202
- When both "use chroot" and "[ daemon chroot] ( # ) " are false, OR the inside-chroot
203
- path of "use chroot" is not "/", rsync will: (1) munge symlinks by default
204
- for security reasons (see "[ munge symlinks] ( # ) " for a way to turn this off, but
205
- only if you trust your users), (2) substitute leading slashes in absolute
206
- paths with the module's path (so that options such as ` --backup-dir ` ,
207
- ` --compare-dest ` , etc. interpret an absolute path as rooted in the module's
208
- "[ path] ( # ) " dir), and (3) trim ".." path elements from args if rsync believes
209
- they would escape the module hierarchy. The default for "use chroot" is
210
- true, and is the safer choice (especially if the module is not read-only).
211
-
212
- When this parameter is enabled * and* the "[ name converter] ( # ) " parameter is
200
+ If ` use chroot ` is not set, it defaults to trying to enable a chroot but
201
+ allows the daemon to continue (after logging a warning) if it fails. The
202
+ one exception to this is when a module's [ ` path ` ] ( # ) has a "/./" chroot
203
+ divider in it -- this causes an unset value to be treated as true for that
204
+ module.
205
+
206
+ Prior to rsync 3.2.7, the default value was "true". The new default makes
207
+ it easier to setup an rsync daemon as a non-root user or to run a daemon on
208
+ a system where chroot fails. Explicitly setting the value to true in the
209
+ rsyncd.conf file will always require the chroot to succeed.
210
+
211
+ It is also possible to specify a dot-dir in the module's "[ path] ( # ) " to
212
+ indicate that you want to chdir to the earlier part of the path and then
213
+ serve files from inside the latter part of the path (with default
214
+ sanitizing and symlink munging). This can be useful if you need some
215
+ library dirs inside the chroot (typically for uid & gid lookups) but don't
216
+ want to put the lib dir into the top of the served path (even though they
217
+ can be hidden with an [ ` exclude ` ] ( # ) directive). However, a better choice
218
+ for a modern rsync setup is to use a [ ` name converter ` ] ( # ) " and try to
219
+ avoid inner lib dirs altogether. See also the [ ` daemon chroot ` ] ( # )
220
+ parameter, which causes rsync to chroot into its own chroot area before
221
+ doing any path-related chrooting.
222
+
223
+ If the daemon is serving the "/" dir (either directly or due to being
224
+ chrooted to the module's path), rsync does not do any extra path sanitizing
225
+ or (default) munging. When it has to limit access to a particular subdir
226
+ (either due to chroot being disabled or having an inside-chroot path set),
227
+ rsync will munge symlinks (by default) and sanitize paths. Those that
228
+ dislike munged symlinks (and really, really trust their users to not break
229
+ out of the subdir) can disable the symlink munging via the "[ munge
230
+ symlinks] ( # ) " parameter. Sanitizing paths trims ".." path elements from
231
+ args that rsync believes would escape the module hierarchy, and also
232
+ substitutes leading slashes in absolute paths with the module's path (so
233
+ that options such as ` --backup-dir ` & ` --compare-dest ` interpret an
234
+ absolute path as rooted in the module's "[ path] ( # ) " dir).
235
+
236
+ When a chroot is in effect * and* the "[ name converter] ( # ) " parameter is
213
237
* not* set, the "[ numeric ids] ( # ) " parameter will default to being enabled
214
238
(disabling name lookups). This means that if you manually setup
215
239
name-lookup libraries in your chroot (instead of using a name converter)
0 commit comments