Wiki: Container runs Wiki as another user and cannot access Sqlite data file

[alexfouche]

Hi,
why switching the user within the container should not be considered as an issue ?

The user inside the container should not change, because it is not what the user running the container expects and implies opening permissions to your data to everyone so that the user 1000 in container can access the data

the usual case i see is that a normal user (for instance alex) on the host machine creates a path to store data in /home/alex/Documents/wikijs_data. Of course /home/alex has restricted permissions to only himself.

The case is by running Wikijs in container launched by user alex, the fact that inside the container Wikijs runs as another user (here 1000) means it can not access the mounted path

# running as user alex
podman run --rm --net host -e DB_TYPE=sqlite -e DB_FILEPATH=/wikijs_data/wikijs_data.sqlite --name wiki -v /home/alex/Documents/wikijs_data:/wikijs_data requarks/wiki:2

=> user 1000 inside the container cannot access /wikijs_data because on the host /home/alex/Documents/wikijs_data would be accessible only by user alex on the host

In fact, even if i moved wikijs data outside my home directory, i still would need to open its permissions to everyone because otherwise user 1000 in the container would not be able to access the data

It is even more a mess when SElinux is involved

[alexfouche]

the fact that the user is changed within the container is told at https://github.com/Requarks/wiki/issues/1047 . But i feel it is a separate issue more about the fact that the user is changed than the original issue

[Smankusors]

I think for temporary solution, you can force the container run as root (which is usually default by most images), by adding -u root in your podman run.

Anyway, why not you chown the wikijs_data folder to uid 1000?

[NGPixel]

It's best practice to run the container in a non-root manner, and it's in fact a requirement for some container deployment systems (e.g. OpenShift). Read for more info: https://engineering.bitnami.com/articles/why-non-root-containers-are-important-for-security.html

You can always run as root if that's an issue (see @Smankusors reply above).

[alexfouche]

I do not run as root, but as my user alex. And in fact on my workstation, my user alex is uid=1000.

But when you run a container with Podman as non-root (here alex), then within the container the user appears as root uid=0. And Wikijs/node runs as user 1000 inside the container, which does not translate as user 1000 on the host system, but rather as a high uid such as 101000

This means even that my files are owned by 1000 (alex) on the host system, the user 1000 inside the container cannot read these files since it is in fact uid=101000

[alexfouche]

i find it sad that the issue was closed without giving me enough time to explain how Podman containers run, how non-root users appear from outside the container, and why i think this is still an issue.

But i must concede the user switching was probably done because of the shortcomings of Docker, which Podman has solved, and now either there are one image for each system, or revert to have Wikijs run as root when using Docker

[NGPixel]

You can always build a new Docker image with the official image as base. Apply the changes you need and use that new image instead.

[Smankusors]

I just tried the podman now and I found out, that podman will change ownership of every file/folder that you bind mount into root user, thus that's why wiki cannot access it, and thus you need to "run as root".

This doesn't happen on docker, where the ownership still same as who created it.

[alexfouche]

@NGPixel I will try to rebuild a podman image without the USER and the chown when i get some time and update my wikijs.

By the way, there is a discussion about the USER directive in the context of Podman there Does Dockerfile USER make sense for podman... and as many other readers i also got lost in the details and something does not look good or i did not completely understood

[lucasbasquerotto]

I want just to put my 2 cents here. In first place, thanks for this great software!

About this issue specifically, I also think that root in the container is a better approach. Using a hardcoded user 1000 in the container can cause multiple issues with permissions, either because your user is not 1000, or because it tries to access a file generated from another container. Furthermore, user 1000 can have lots of privileges in the host (who knows?). One of the main benefits of docker is the portability among diferent machines with different configurations, and hardcoding the user in the dockerfile removes that portability.

In general, I consider docker pretty safe if you don't run a container with something like -v /:/host or anything of the sort. The main concern about running as root in a container is if the process escape the container. But this would be a huge security flaw with containers, and in this case you should consider if running docker as root is actually safe, because a bug in docker could cause the user in the container escalate to root, even if the user itself is not root, because the daemon/server is still root. An example is this issue in which a user in the container was be able to become root, that, although fixed, doesn't mean that every possible security vulnerability of that type is fixed.

Aside from that, the user running docker must have sudo privileges (which could be considered a security concern). And on top of that, if the user in the container escalate to your non-root user in the host, it should already be considered a big issue (having access to your ssh keys, maybe bank account and other stuff if it's in your local machine).

If you really want to be safe, I think podman is a better alternative (or running docker rootless, which I haven't tested), because the main issue here is to make sure that the user in the container doesn't escalate to root in the host, and the best way I consider to do that is to never run a container as root (or having root privileges, like adding your user in the docker group) in the first place.

If you are concerned about the user in the container escaping and have access of your user stuff (even if it's not root), like ssh keys, then you can run the container as another user in the host, this doesn't remove the flexibility and portability of containers, like hardcoding the user in the dockerfile.

But like I said before, I still consider running docker containers as root still considerably safe, I still haven't seen an escalation of privileges from root in the container to root in the host, and, even if that is possible, it should be very difficult to happen (as long as you don't map your root volume, the docker socket, and don't add more capabilities to the container).

But in the end is your choice to make, and I'm ok with whatever choice you make, this is only my 2 cents.

[NGPixel]

@lucasbasquerotto While I agree with you, the only reason it's running as non-root is because platforms like OpenShift will simply not run at all if running as root. If that wasn't the case, I would see no reason to hardcode the node user in the dockerfile.

[lucasbasquerotto]

@NGPixel OK, that seems like a valid reason. I haven't used Openshift, but unfortunately it seems that such a requirement of Openshift ends up making things more difficult for users that want to run the container in another environment (at least when dealing with volumes) :/ Thanks for the response, btw.