Improve documentation for first time users #187
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -48,6 +48,9 @@ docker compose stop | |
| docker compose up -d | ||
| ``` | ||
|
|
||
| Please keep in mind that the _numeric_ user and group ids are shared between the local docker host and the docker container (user/group _names_ are not). That means the user running inside the container can read and write all files on the host with the same user id as photoprism is running at. The container runtime tries restricts the available paths but as soon as a security vulnerability circumvents this docker imposed restrictions full access to the entire host with this user id is possible. Threfore nover run as root or with a low user id of regular users of the docker host. | ||
|
There was a problem hiding this comment. Could you please share an example of this security vulnerability? There was a problem hiding this comment. A good writeup to test/understand this user feature can be found here: A way to "use" this (and get root) is written here: Even as the examples above use root / UID 0. it is the same for docker running with all user ids - the process inside the container can potentially access all files outside available to the same user id. Using (for example) UID 1000 or 1001 will give potential access to the files of the primary Linux user (as most Linux distributions start numbering with 1000 for regular users). Using a high user id not used anywhere else on the docker host is a forward-looking security technique to not get owned if there is a security vulnerability found inside the Linux kernel or Docker daemon or some other software running inside the container. And all Docker security best practices mention a privilege escalation attack as possible scenario to take care of. There is no real attack right now but you never now - better safe than sorrow.. e.g.
There was a problem hiding this comment. just a note: restricting the UID to some specific values prevents Photoprism from running inside OpenShift Clusters as OpenShift automatically assigns a high random user id to every container started. I have not tested it right now but would assume its not working there... |
||
|
|
||
|
|
||
| ## Remove Passwords From the Environment | ||
|
|
||
| Passwords specified directly in a `docker-compose.yml` file or otherwise passed to the container environment may pose a security risk. As an alternative, they can be set in an [options.yml](../config-files/index.md) file located in the _config_ [storage folder](../docker-compose.md#photoprismstorage): | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing
portswould be better? It would limit access to the Docker network.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your hint implies running mysql with docker-compose in the same setup.
My suggestion is much more generic and preferred for all kind of database setups (not only Photoprism).
And you would not believe how much people i talked to do not even thought it is easily possible to restrict access in this way. So document it here might people start thinking about it...
Running MariaDB inside docker is (performance wise) the lease favored (aka slowest) variant. It is much better to use a common db host on real iron with some bit of tuning to get much faster SQL responses. And it is easier to maintain/backup/monitor than a dozen different DB container. For these setup restricting "ports " will not help.
And we do not talk about failover cluster or similar here... Or you can use a DBaaS from some places if you host the app somewhere else. Restricting access to defined IP addresses is also helpful not using docker at all but running Photoprism as "native" app.
Alternative: Running it in the same compose setup or running DB directly on the docker host a setup sharing Unix domain sockets (e.g. /var/run/mysql/mysqld.socket) would be much better than ports restriction to prevent foreign logins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes a docker-compose setup is shown on the lines before this change.
About using or not using Docker, that may go in a different section since right now it only describes the common installation with a container for the database.
https://github.com/photoprism/photoprism/blob/9f1eee6b1e7e6fadac55bb3b6098714648f81bf8/compose.mariadb.yaml#L16-L17
If
portsare removed, the access from the host or external network won't work anymore, but Photoprism will work without any issue since it's on the same Docker network.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - the code snipped above shows the docker-compose-all-in-one setup. But this is also the exact place to configure the database connection properties using Photoprism only as docker image and with some external database.
And most of the other information are valid for combined compose setup as well as an divided setup.
Here its up to you if you want one file with database hints or different one for compose and others or just create different sections... I don't hang to, just realized its good to give people different hints on how to secure their setups. Some do, some do not...
And your remark about the port is good - this should be added to the compose file - either as active by default or uncommented and some comments added , similar to many other parameter and env vars within this compose file you can download for fast setup. And mentioned in the database readme here.