Allow in-container root access using password-less sudo.

[MrHighVoltage]

As the title says, allowing sudo inside the container would potentially allow users to install additional applications etc..
But, it poses a security risk, if the containers run in root mode, since with mounted drives, you have access to the hosts file system with elevated privileges.

For this, I would suggest and additional parameter/ENV variable to starting the container. If it is set, the start script rewrites the sudoers file to include the current user, but it requires the container to be started as uid 0 (inside the container), which requires a bigger rework of the startup (seeking inspiration in distrobox).

This option should, of course, be optional, especially in hosted/non-local setups.

[MrHighVoltage]

Also, referencing #137 , as this can go hand in hand with a rework.

[MrHighVoltage]

Taking inspiration from other projects like distrobox, this could be potentially be solved with a rework of the startup functionality. The initial start script in the container would be launched as (in-container) root, modifying the permissions of common files, editing sudoers etc... After the setup has been done, the process would switch to the requested user (set by environment variables for example) and start the actual UI etc..

Advantages:

• We can remove the libnss_wrapper workaround for the container user, since we can create actual users. Using rootless mode with podman even copies the host user.
• We can simply modify files in the container (like /etc/sudoers) on startup, giving huge flexibility for the startup.

Disadvantages:

• Security implications, since root inside the container is root outside the container (when using Docker/podman in root mode). This can be used to do malicious things, also on the host.
• More complicated startup
• Possible incompatibility with the current start scripts.

We could work around some of these issues by making features available but disabled by default (lke sudo), and additionally keep a legacy startup mode (when not started as root, but another user) where everything is kept as default.

[ijamroll]

I guess this can be done using the start_shell.sh script , please refer to README.md

[MrHighVoltage]

Yes, fully running a container can already be achieved with all start scripts by changing the user id. For the shell start script it is even default.
But, this issue should process towards a more flexible approach, where the container is started as root in any way, then inside the container, the necessary changes to the configuration files are made, depending on the requested final user and features (like sudo etc.).
But, this is a bigger rework of the startup script, which currently is not on our priorities.