Docker commands demanding root privilegies

[rafaellehmkuhl]

Newly installed image:

pi@companion:~ $ docker ps
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json: dial unix /var/run/docker.sock: connect: permission denied
pi@companion:~ $ sudo docker ps
CONTAINER ID   IMAGE                                     COMMAND                  CREATED          STATUS          PORTS     NAMES
13d341bd40f3   bluerobotics/companion-core:master        "/bin/sh -c '/usr/bi…"   14 minutes ago   Up 14 minutes             companion-core
c47870608bec   bluerobotics/companion-bootstrap:master   "/bin/sh -c /main.py"    17 minutes ago   Up 14 minutes             companion-bootstrap
pi@companion:~ $ 

I think we should enable docker for non-root users.

[slayer321]

Hey @rafaellehmkuhl, I am new to open source and will like to contribute to this project, can you guide me on what needs to be done.

[rafaellehmkuhl]

Hey @slayer321, how are you doing?

Of course I can guide you!

The PR itself should be as simple as adding the usermod -aG docker $USER command to the /install/install.sh script, but we need to test it to see if anything breaks.

Do you happen to have an Raspberry Pi to test the install script on? If not, you can do the PR and I can test it for you.

[slayer321]

Hey @rafaellehmkuhl, I'm doing great. Thank you for guiding me :) Just wanted to ask do I need to add this command also sudo groupadd docker, as in enable docker for non-root users the first step is to add this command and I didn't found this command in /install/install.sh script . Or I just need to add this command usermod -aG docker $USER. I don't have a Raspberry Pi to test this script on. So I will be just opening the PR for it .

[rafaellehmkuhl]

Despite not existing on the install script itself, the docker installation already adds the docker group, because once the install is done, the docker group shows up, so just the usermod should be enough.

Also please add an echo saying this is being done, like the other commands.

And no prob about the Rasp, I can test it for you.

[patrickelectric]

It would be great with can have our own group that includes docker and necessary hardware access for the flight controller

[joaoantoniocardoso]

I've just checked a freshly installed 1.1.1 image and these are the groups:

• pi
• adm
• dialout
• cdrom
• sudo
• audio
• video
• plugdev
• games
• users
• input
• render
• netdev
• docker
• gpio
• i2c
• spi

[joaoantoniocardoso]

@patrickelectric I believe the hardware is dialout, gpio, i2c, spi, and docker is docker, so we might already have everything needed.

[patrickelectric]

We should create a new group that has all the necessary groups for BlueOS. Right now we run as root to circumvent this problem.

[joaoantoniocardoso]

We should create a new group that has all the necessary groups for BlueOS. Right now we run as root to circumvent this problem.

If I understood it correctly, I don't support this idea, it would be okay if Linux allowed nested/embedded groups, but that is not the case. As an alternative, we would need to create udev rules to change a lot of stuff to have a unified group that will be almost the root itself, and whenever we discover something that would require another permission, we would need to add another udev rule to change the group of the node/device.

In my opinion, it's much better to use Linux as it is, adding the user to the necessary groups as we discover the need to use them.

[patrickelectric]

That's is a possible solution.

On Mon, Oct 23, 2023, 08:40 João Antônio Cardoso @.***> wrote:

We should create a new group that has all the necessary groups for BlueOS. Right now we run as root to circumvent this problem.

If I understood it correctly, I don't support this idea, it would be okay if Linux allowed nested/embedded groups, but that is not the case. As an alternative, we would need to create udev rules to change a lot of stuff to have a unified group that will be almost the root itself, and whenever we discover something that would require another permission, we would need to add another udev rule to change the group of the node/device.

In my opinion, it's much better to use Linux as it is, adding the user to the necessary groups as we discover the need to use them.

— Reply to this email directly, view it on GitHub https://github.com/bluerobotics/BlueOS/issues/292#issuecomment-1775225162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJIYCPQ3CYKF4O7C4T5BK3YAZXUTAVCNFSM45WUYEV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGUZDENJRGYZA . You are receiving this because you were mentioned.Message ID: @.***>