Mention cause and solution for "permission denied" when running from …

…init service.

README.md

@@ -154,6 +154,12 @@ time.  These are not installed by default. You can find init scripts for
 Debian / Ubuntu at `/usr/share/doc/scriptform/scriptform.init.d_debian` and
 for Redhat / Centos at `/usr/share/doc/scriptform/scriptform.init.d_debian`. 
 
+**NOTE**: If you use an init script, Scriptform will run as user `root`, which
+will cause Scriptform to automatically drop privileges to user `nobody` and
+group `nobody` when executing shell scripts. This may cause "permission
+denied" problems! See the "Execution security policy" chapter in the User
+Manual for more information.
+
 To install the init script:
 
 For **Debian / Ubuntu** systems:

doc/MANUAL.md

@@ -1167,6 +1167,17 @@ in some cases:
 * If Scriptform itself is running as a non-root user, scripts will be executed
   as that user.
 
+If you use an init script, Scriptform will run as user `root`, which will
+cause Scriptform to automatically drop privileges to user `nobody` and group
+`nobody` when executing shell scripts. This may cause "permission denied"
+problems! There are a few possible ways to work around this:
+
+* Make sure the user or group `nobody` has rights to view and execute the
+  scripts. The form configuration itself should probably not be viewable by
+  user `nobody` since it may contain passwords.
+* Modify the init or systemd script to run as a different user.
+* Add `run_as` properties to each form definition to specify the user it
+  should run as.
 
 
 
@@ -1258,6 +1269,7 @@ If such a header is seen, Scriptform won't perform validation of the password
 and just assumes the username is correct.
 
 
+
 ## <a name="cust">Form customization</a>
 
 ### <a name="cust_css">Custom CSS</a>