Mention cause and solution for "permission denied" when running from init service.

pull/7/head
Ferry Boender 7 years ago
parent a8425a57a6
commit adf3f627ce
  1. 6
      README.md
  2. 12
      doc/MANUAL.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:

@ -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>

Loading…
Cancel
Save