Mention a potential bash security issue with openssh forced commands.

support/rrsync.1.md

@@ -22,6 +22,10 @@ transfer in one of two easy ways:
 * forcing the running of the rrsync script
 * forcing the running of an rsync daemon-over-ssh command.
 
+Both of these setups use a feature of ssh that allows a command to be forced to
+run instead of an interactive shell.  However, if the user's home shell is bash,
+please see [BASH SECURITY ISSUE](#) for a potential issue.
+
 To use the rrsync script, edit the user's `~/.ssh/authorized_keys` file and add
 a prefix like one of the following (followed by a space) in front of each
 ssh-key line that should be restricted:
@@ -107,6 +111,26 @@ overrides.
 The script (or a copy of it) can be manually edited if you want it to customize
 the option handling.
 
+## BASH SECURITY ISSUE
+
+If your users have bash set as their home shell, bash may try to be overly
+helpful and ensure that the user's login bashrc files are run prior to
+executing the forced command.  This can be a problem if the user can somehow
+update their home bashrc files, perhaps via the restricted copy, a shared home
+directory, or something similar.
+
+One simple way to avoid the issue is to switch the user to a simpler shell,
+such as dash.  When choosing the new home shell, make sure that you're not
+choosing bash in disguise, as it is unclear if it avoids the security issue.
+
+Another potential fix is to ensure that the user's home directory is not a
+shared mount and that they have no means of copying files outside of their
+restricted directories.  This may require you to force the enabling of symlink
+munging on the server side.
+
+A future version of openssh may have a change to the handling of forced
+commands that allows it to avoid using the user's home shell.
+
 ## EXAMPLES
 
 The `~/.ssh/authorized_keys` file might have lines in it like this: