sudo / root problem

[LoSunny]

When I start the container, login to noVNC, try to open a terminal and run sudo apt update, it will return an error

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

When I run su root, and enter the default password headless, it will print

$ su root
Password: 
su: Authentication failure

According to the docs, I should be able to enter sudo, but I can't. Is there something wrong?

[accetto]

Hello,

thank you for you feedback. However, I'm not able to reproduce the issue. Can you provide more information abou your environment?

Are you on Windows or Linux? Does your container run locally or in the cloud? Which image have you used?

This is what I've got by using the image accetto/ubuntu-vnc-xfce-g3:latest, running it locally on Linux and connecting to it via noVNC:

Regards, accetto

[LoSunny]

Here is part of my docker-compose.yml file

services:
  ubuntu:
    image: accetto/ubuntu-vnc-xfce-g3:latest
    ports:
      - 6901:6901

The container is deployed in okteto cloud

[accetto]

I'm afraid that okteto could be limiting root access. Have you checked their security policy? I would also use different port binding. The local port 6901 could be already in use or blocked. Try something like 36901:6901.

[LoSunny]

okteto allow us to bind to any http port, so it shouldn't be a problem. But what do you mean by security policy? This? https://www.okteto.com/docs/cloud/multitenancy/

[accetto]

I mean that cloud providers often limit usage of elevated permissions, so it could be the case here. What do you see as the actual user in your container? What is the output of the command id? Have you tried to set the root as the explicit container user? Like docker run --user 0 ...

[LoSunny]

$ id
uid=1001(headless) gid=0(root) groups=0(root),27(sudo)

When I change the user to USER 0 through a Dockerfile, I'm able to execute root commands like apt update

[accetto]

It's interesting, the id output is correct.

You can always set the user to 0 (=root) in the Dockerfile, but some applications will refuse tu run under the root account.

Btw, does it also work if you set the user 0 in your compose file?

If you don't need apt for general use, but only for installing some particular applications, then you can also extend the Dockerfile to instal them before switching to the non-root user 1001.

The problem seems to be somewhere outside the container. You can check also this issue, for example.

Btw, do you bind any external volumes to your container?

[LoSunny]

Btw, does it also work if you set the user 0 in your compose file? Yep

Btw, do you bind any external volumes to your container? No

Yes I can install all the packages before starting the container with Dockerfile, but sometimes when I want to test a new software, I won't be able to install its dependency easily.

[accetto]

I'm afraid that the problem has something to do with the restricted capabilities described in the section Pod Security Policies.

If you would closer describe your use case and provide an example of the compose file you use, I could find some time to try to reproduce it on okteto. Unfortunately I cannot reproduce the problem in my environment.

[LoSunny]

There is the steps to re-produce the problem in okteto

1. Create an account
2. Create a namespace
3. Click "Launch Dev Environment"
4. Select "Git URL"
5. Paste it in https://github.com/LoSunny/ubuntu-vnc-xfce-g3-test
6. Wait until the container launches
7. The URL should be shown in Endpoints: xxxxxx

[accetto]

Till now I can only confirm the behaviour. I'm trying to pinpoint the problem, but no success yet.

The error message sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? seems to be misleading, because:

1. It's possible to run a container under the root (0) account. So the root account is not generally prohibited.
2. I've tested that I can successfully set the SUID bit, so the file system supports it.

I've also found, that you cannot actually set the capabilities, even if there is an example like cap_add: - ALL in the documentation. There is only one capability, which is not refused, but it also doesn't solve the problem.

It seems more and more like an Okteto's bug (?).

Have you tested it also on some other cloud, maybe?

[LoSunny]

If that's the case, then it might be an issue with okteto cloud provider. As I cannot re-produce the issue on my MacBook Docker Desktop

[marisancans]

I'm having similar issues. I use this image as a base and install other software on it in Docker, but I have to set USER 0 otherwise it asks for password. Everything works, but if I later run the image with docker-compose and set user to 1000 i get lots of permission issues:

/dockerstartup/vnc_startup.rc: line 52: /home/headless/.vnc/passwd: Permission denied
chmod: changing permissions of '/home/headless/.vnc/passwd': Operation not permitted
/dockerstartup/vnc_startup.rc: line 60: /home/headless/.vnc/config: Permission denied
/dockerstartup/vnc_startup.rc: line 74: /dockerstartup/vnc.log: Permission denied
/dockerstartup/vnc_startup.rc: line 83: /dockerstartup/vnc.log: Permission denied

I also tried to build the image myself by enabling the user override? FEATURES_USER_GROUP_OVERRIDE=1 DOCKER_BUILDKIT=1 ./docker/hooks/build main latest But this doesn't help, or I don't understand clearly how I should do it

[accetto]

Hello @marisancans ,

sorry for the late answer, but I've noticed your question only a few days ago.

I've tried to reproduce the problems, but by me everything worked OK.

Maybe you've bound the dockerstartup/ folder as an external volume, haven't you?

If not, then try to set the permissions by adding the following to your Dockerfile:

RUN "${STARTUPDIR}"/set_user_permissions.sh "${HOME}"

It'll help, if you provide more information about your environment and what packages you try to add.

Anyhow, I've added two new files Dockerfile.extend and example.yml that show how to use the images as the base for new images and how to switch users in compose file. Both files worked fine in my environment.

Regards, accetto

[capsulecorplab]

@accetto First of all, thank you for creating this docker image! A friend of mine introduced me to your project as a lighter weight kasm alternative that wasn't constrained to the web browser, which is great because I'm running out of hard drive space from all the images I've pulled or built locally and I really miss my keybindings that are otherwise inaccessible via kasm :smiling_face_with_tear:

I ran into a similar issue as @marisancans and tried your suggested fix of adding the RUN "${STARTUPDIR}"/set_user_permissions.sh "${HOME}" line in my Dockerfile. However, I'm encountering the build error /bin/sh: 1: /dockerstartup/set_user_permission.sh: not found. I ran the base image locally to check that the /dockerstartup/set_user_permission.sh file path exists and it seems to be there. Any idea as to what might be the issue?

Here's the build error on my CI https://github.com/capsulecorplab/ltc-workspace-image/actions/runs/3606819773/jobs/6078430721#step:5:1752

[accetto]

@capsulecorplab Thank you for your feedback.

I see the following two lines in the log:

ERROR: failed to solve: executor failed running [/bin/sh -c $STARTUPDIR/set_user_permission.sh $HOME]: exit code: 127
Error: buildx failed with: ERROR: failed to solve: executor failed running [/bin/sh -c $STARTUPDIR/set_user_permission.sh $HOME]: exit code: 127

I think, that you need to assure using the bash shell, not sh. For example, this is what I have in my GitLab script:

variable:
   SHELL: "/bin/bash"

However, additionally to that I had to extend the docker executor image by installing the "proper" GNU bash version, because the image itself is based on alpine:

Actually, this is the complete Dockerfile I currently use for my executor image:

# docker build -f Dockerfile.docker -t g3/docker:20.10.21 .

### This is the docker-in-docker executor image.
### The additional packages are required only by the G3 projects.

FROM docker:20.10.21

RUN apk --no-cache add \
    bash \
    curl \
    git \
    grep \
    sed \
    wget

You have also to ensure, that all script files are executable. This is what I do in my GitLab script after cloning the repository:

### make all script files executable
- find . -name "*.sh" -exec chmod +x '{}' \;
- chmod +x docker/${BUILDER_PROJECT}/hooks/*

Please let me know if it helped. Otherwise we'll investigate it further.

Regards, accetto

[capsulecorplab]

@accetto How would I go about setting the shell path for a local build? I get the same build error when I attempt to build the image locally with docker-compose build.

[accetto]

Usually it's set as an environment variable SHELL=/bin/bash. Check waht you have on your machine:

echo $SHELL

which bash

### my output
/usr/bin/bash

bash -version

### my output
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please try to use the provided builder.sh script. Please be sure to exucute it from the project's root directory:

./builder.sh latest all-no-push

Does it work? What is in the scrap_builder.log?

[capsulecorplab]

Seems to be set correctly

$ echo $SHELL
/bin/bash

$ /bin/bash -version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
captainpike@captainpike-ThinkPad-T490:~/repo/iiac-workspac

$ ./builder.sh latest all-no-push

==> EXECUTING @2022-12-03_11-05-45: ./builder.sh 


==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/pre_build dev latest


==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/cache dev latest


==> G3-CACHE hit file 'tigervnc-1.12.0.x86_64.tar.gz' in section 'tigervnc'

==> G3-CACHE hit file 'v1.3.0.tar.gz' in section 'novnc'

==> G3-CACHE hit file 'v0.10.0.tar.gz' in section 'websockify'


==> FINISHED  @2022-12-03_11-05-45: ./docker/hooks/cache 


Removing helper files

+ docker build -f ./docker/Dockerfile.xfce --build-arg BUILDKIT_INLINE_CACHE=1 --build-arg BASEIMAGE=ubuntu --build-arg BASETAG=20.04 --build-arg ARG_APT_NO_RECOMMENDS=1 --build-arg ARG_TIGERVNC_DISTRO=x86_64 --build-arg ARG_TIGERVNC_VERSION=1.12.0 --build-arg ARG_NOVNC_VERSION=1.3.0 --build-arg ARG_WEBSOCKIFY_VERSION=0.10.0 --build-arg ARG_MERGE_STAGE_VNC_BASE=stage_novnc -t accetto/:latest_helper ./docker
invalid argument "accetto/:latest_helper" for "-t, --tag" flag: invalid reference format
See 'docker build --help'.

$ cat scrap_builder.log 

==> EXECUTING @2022-12-03_11-05-45: ./builder.sh 


==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/pre_build dev latest


==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/cache dev latest


==> G3-CACHE hit file 'tigervnc-1.12.0.x86_64.tar.gz' in section 'tigervnc'

==> G3-CACHE hit file 'v1.3.0.tar.gz' in section 'novnc'

==> G3-CACHE hit file 'v0.10.0.tar.gz' in section 'websockify'


==> FINISHED  @2022-12-03_11-05-45: ./docker/hooks/cache 


Removing helper files

+ docker build -f ./docker/Dockerfile.xfce --build-arg BUILDKIT_INLINE_CACHE=1 --build-arg BASEIMAGE=ubuntu --build-arg BASETAG=20.04 --build-arg ARG_APT_NO_RECOMMENDS=1 --build-arg ARG_TIGERVNC_DISTRO=x86_64 --build-arg ARG_TIGERVNC_VERSION=1.12.0 --build-arg ARG_NOVNC_VERSION=1.3.0 --build-arg ARG_WEBSOCKIFY_VERSION=0.10.0 --build-arg ARG_MERGE_STAGE_VNC_BASE=stage_novnc -t accetto/:latest_helper ./docker
invalid argument "accetto/:latest_helper" for "-t, --tag" flag: invalid reference format
See 'docker build --help'.

[accetto]

Oh, I see. The BUILDER_REPO environment variable is not set. It defines the name of your image on the local stage. See the part invalid argument "accetto/:latest_helper".

Please be sure that you've edited and sourced the secrets.rc file before building the images. The file can be named differently or you can set all necessary variables also manually. Check the file readme-util-readme-examples.md.

[capsulecorplab]

My repo probably isn't properly configured to run the builder scripts at the moment; I've mostly just been building images with the docker-compose.yml and Dockerfile using the docker-compose build command. It's worth noting the image builds just fine with this approach if I comment out the lines that are setting and calling /dockerstartup in the Dockerfile, but then I run into the permission issue when trying to start up the image with docker-compose up.

[accetto]

The following two changes could help with the permission problem. However, you have to test it in your environment, because by me everything works fine.

Scenario 1

Try to change the following line in the Dockerfile:

### from
&& chmod 755 -R "${STARTUPDIR}" \

### to
&& chmod 777 -R "${STARTUPDIR}" \

Scenario 2

Disable the following lines in the Dockerfile and do those settings in your compose file.

USER 1001
ENTRYPOINT [ "/usr/bin/tini", "--", "/dockerstartup/startup.sh" ]

Scenario 3

You can optionally test it also with the alternative entry point line in the `Dockerfile. The VNC server will not be started, but you'll find out, if there is a problem with the startup script itself or its permissions.

ENTRYPOINT [ "/usr/bin/tini", "--", "tail", "-f", "/dev/null" ]