forks/molly-brown
1
0
Fork 0
Code Releases Activity

Update README to reflect movement of unix security stuff out of config file into command line switches.

Browse source
This commit is contained in:
Solderpunk 2023-02-23 18:57:56 +01:00
parent 212c9f79fb
commit 67386cd118
1 changed files with 18 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
README.md
View file

@ -107,6 +107,16 @@ command line option to tell Molly Brown where to find it.
### Running
The `molly-brown` executable recognises the following command line
switches:
* `-c`: Used to specify a config file.
* `-C`: Used to specify a directory to chroot to (unix only).
* `-u`: Used to specify the name of an unprivileged user which
Molly Brown should switch to running as if started as
root or run as a setuid executable (unix only).
* `-v`: Print version number and exit.
Molly Brown does not handle details like daemonising itself, changing
the user it runs as, etc. You will need to take care of these tasks
by, e.g. integrating Molly Brown with your operating system's init
@ -318,13 +328,14 @@ can be set readable by the user who owns the binary, but not readable
by the user who runs the binary. CGI processes will then be unable to
read any of those sensitive files. If the binary is not SETUID but is
run by the superuser/root, then Molly will change its UID to that of
the `nobody` user before accepting network connections, so CGI
processes will again not be able to read sensitive files. Note that
while these measures can protect Molly's own sensitive files from
CGI processes, CGI processes may still be able to read other sensitive
files anywhere else on the system. Consider chroot()-ing Molly Brown
into a small corner of the filesystem (see `ChrootDir` below) to
reduce this risk.
the `nobody` user (or any other user specified with the `-u` option)
before accepting network connections, so CGI processes will again not
be able to read sensitive files. Note that while these measures can
protect Molly's own sensitive files from CGI processes, CGI processes
may still be able to read other sensitive files anywhere else on the
system. Consider chroot()-ing Molly Brown into a small corner of the
filesystem (see discussion of the `-C` option at the start of the
Running section) to reduce this risk.
When compiled on GNU/Linux with Go versions 1.15 or earlier, Molly
Brown is completley unable to reliably change its UID due to the way
@ -387,18 +398,6 @@ facility.
status code of 60. Requests made with a certificate not in the list
will cause a response with a status code of 60.
### Security settings
* `ChrootDir`: A directory to which Molly Brown should chroot(),
making it more difficult for the server itself or spawned CGI
processes to read or write any files higher in the hiearch. The
chroot happens immediately after reading the config file. All other
paths specified in the config file (e.g. `DocBase`, `KeyPath`,
`AccessLog`) must be specified relative to `ChrootDir`.
* `UnprivUsername`: The username of an unprivileged user on the system
which MollyBrown will change setuid() to if started by the superuser
or when run as a setuid binary (default value "nobody").
## .molly files
In order to allow users of shared-hosting who do not have access to