feat: Rootless containers

[emrahcom]

This PR allows Jitsi containers to run without using root account.

Main changes:

• s6-overlay is upgraded to v3.2.0.2

• All processes are run by a non-root user: s6

• Currently, container's filesystem is still writable but the active user is s6. So, it cannot write into the root's folders.

• Config files are created in /run by using templates and provided config files (from /config)

• The writable folders for s6 are:

  • /run
  • /tmp
  • Folders in the mounted volumes with write permission (writable folders should have 777 as mode)

• Volumes are updated to differ read-only and writable volumes:

  • /config contains read-only config files
  • /storage contains created files during the runtime such as recordings, logs, etc.
  • /tmp contains created temporary files the runtime

• Expected folders on host:

mkdir -p ~/.jitsi-meet-cfg/prosody/{config,prosody-plugins-custom}
mkdir -p ~/.jitsi-meet-cfg/{jibri,jicofo,jigasi,jvb,web}

mkdir -p ~/.jitsi-meet-cfg/storage/{jibri,prosody,transcripts}
chmod 777 ~/.jitsi-meet-cfg/storage/jibri
chmod 777 ~/.jitsi-meet-cfg/storage/prosody
chmod 777 ~/.jitsi-meet-cfg/storage/transcripts

mkdir -p ~/.jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}
chmod 777 ~/.jitsi-meet-cfg/tmp/web-crontabs
chmod 777 ~/.jitsi-meet-cfg/tmp/web-load-test

• jibri container doesn't have CAPS_SYS_ADMIN anymore. Therfore Chrome is run with --no-sandbox.

My plan is to create a second PR to make container's filesystem completely read-only after a while. Actually this also works in my test but I don't want to make it harder to debug.

[saghul]

Sorry for the exec comments, I got carried away during review ;-) I can make those after this lands.

[saghul]

I'll give this a try shortly @emrahcom, thanks a lot for the swift responses to my comments!

[emrahcom]

Thank you very much for your helps.

[saghul]

Hey @emrahcom quick update: I will start testing the end of this week or the next.

Something important we need to handle here is migrating the XMPP data from existing installations since it may contain user accounts.

[emrahcom]

I will check the option to use ~/.jitsi-meet-cfg/storage/prosody as Prosody's data_path.

[emrahcom]

I updated my first post (added ~/.jitsi-meet-cfg/storage/prosody).

A fix was added to get Prosody accounts from the old setup.

[emrahcom]

Hi @saghul, I have an idea that would make merging easier. This is:

• creating base and base-java images on jitsi-contrib/docker-images
• creating PR covering only one container at a time using the images from jitsi-contrib/docker-images
• when all PRs (except base and base-java) are merged, updating base and base-java in this repo

Currently, this PR looks big and the repo is being updated all the time.

What do you think?

[saghul]

Hey @emrahcom ! So sorry for the delay, the Prosody 13 release has certainly stolen some cycles.

I think it's best to go all in here.

The conflicts should be easy to solve, we can likely do that before the merge.

I'm setting some time aside next week to test this properly.

[emrahcom]

Hi @saghul, if there is anything I can do to help the process, please let me know.

[securitykernel]

Hi @saghul, Germany's Center for Digitial Sovereignity (ZenDiS) was happy to sponsor this work as part of openDesk 🚀 .

We would like to see this integrated as soon as possible. Would you mind taking a look at this again?

[github-actions[bot]]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.