Use a directory writable by nonroot.

[amouat]

The Dockerfile should use a directory writeable by nonroot for sqllite.

Fixes #6

Signed-off-by: Adrian Mouat [email protected]

[willnorris]

oh, duh... that makes sense! However, even with these changes (and rebuilding and tagging), I still see the out of memory error...

$ docker run -it --rm -v /tmp/golink:/home/nonroot ghcr.io/tailscale/golink:main
2022/12/01 17:47:05 NewSQLiteDB("/home/nonroot/golink.db"): unable to open database file: out of memory (14)

[amouat]

You've mounted a directory that's not writable by the user. In this case it's the permissions of the directory on your host that are the problem. Try running:

$ chmod go+rw /tmp/golink
$ docker run -it --rm -v /tmp/golink:/home/nonroot ghcr.io/tailscale/golink:main

EDIT: Thinking about this again, /tmp should be writeable. It works for me:

$ docker run -it --rm -v /tmp/golink:/home/nonroot test
...

Where test is my local image. It doesn't work with the current ghcr.io/tailscale/golink:main image.

[amouat]

If this is the expected use case there a few things we can do:

1. Just run the container as root. I don't like this, as it's not great from a security pov.
2. Change things so that the container starts as root, then does a chown on the directory to the nonroot user before changing user to the nonroot user. This could be done in an entrypoint script, but that would require adding a shell to the image (unless you create a binary).
3. Just document that users will need to make the directory accessible to the nonroot user

[amouat]

Actually, I'm just thinking if you're running on a Mac in Docker Desktop, this might be because of the use of /tmp. Try using a directory in your home directory with chmod. Otherwise double-check /tmp is listed in preferences -> resources -> File Sharing (it should be).

[willnorris]

This is on Windows with WSL. And yeah, it seems to be because of the default permissions that docker creates /tmp/golink with. And none of those options seem great. I guess this is just part of using the wolfi static image?

[willnorris]

err... I guess the wolfi static image is only relevant because it runs as non-root by default (which is a better choice for security, but results in this well-known issue)

[amouat]

Ah, WSL explains things. I assume WSL works fine without the volume mount?

My suggestion would be:

• use this patch
• add documentation explaining how to use volumes
• optionally add a second dockerfile that creates an image which runs as root and tag golink:main-root (the Google distroless images do something similar)

[willnorris]

If I'm reading this table correctly, I think the Google distroless images do the inverse... they default to root and provide "nonroot" tagged images. And that does seem like the pragmatic choice here as well. I think we'll switch to running as root by default (even if it's less ideal) and later consider updating CI workflows to do a nonroot tag as well.

[amouat]

You're right. I'm still of the opinion that in this case nonroot should be the default for security reasons, but it's certainly arguable.

[willnorris]

okay, turns out the docs are too bad for instructing people how to handle nonroot. Added docs to your PR branch, merging now.

[peterbraden]

Even after chowning the directory to 645532, I get tsnet: lstat /home/nonroot/.config/tslib-golink: permission denied - am I misreading something?