What I do not understand. When I run dnf install inside container it ask to have root passwd and when I give it does not accept even that it is the same as I am using outside toolbox. And why it does ask it. I was using earlier and no need for superuser. Though that this is the whole thing that you are using container. No I am puzled.
Hello @juhafinlandvoaa;
For some dnf operations, you need sudo, not root capability. Since toolbox is a container created in your user namespace, you are effectively root while inside that container. So when you use dnf in toolbox, and the installed package would normally require root privileges to be installed, you will need to use sudo. Even in standard workstation there are packages that require root privileges to install.
So for example, I created a toolbox container just now and entered it. I issued the command dnf info vim which results in a long list of vim related packages, but I’m only interested in vim-enhanced for my purposes. So I do the following …
[toolbox ~]$ dnf install vim-enhanced
Error: This command has to be run with superuser privileges (under the root user on most systems).
[toolbox ~]$
so I run it again as sudo thus …
[toolbox ~]$ sudo dnf install vim-enhanced
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
But I don’t need to enter my user password since I am root by default in my toolbox container. So it is a bit confusing, but there is some reasoning behind it.
Yes, I was using sudoing aka superuser. Pasword do not work nor simple enter. I mean inside container. All other make sens. It has to do with a permissions of certain files and so on. You are right sometimes superuser is needed in standard OS when dnf is used.
I am talking about inside the container, I don’t have to enter the password, even on a newly created container.
toolbox create then toolbox enter was the order of the commands I issued in the terminal. Then while inside the toolbox container, I installed vim-enhanced as I wrote above. I had to use sudo to do it.
Hi @juhafinlandvoaa,
toolbox asks you the password when you run the sudo command? That’s odd.
I think that the default behavior is that you can use sudo without password inside the toolbox’s container.
Could you show your toolbox’s version and the steps you followed to get to this point?
It is odd. dnf search mythtv works but it does not even try to find any mythTV and then return no such a thing like usually. tbs is manufacture of PVR PCie card. toolbox version 0.0.92
toolbox create --container tbs
toolbox enter --container tbs
[xxmexx@toolbox xxmexx]$ sudo dnf install mythtv
[text message created by OS]
[sudo] password for xxmexx:
Then not sudo passwd nor enter works. I can pray but when I do go to sleep.
BTW, the interesting thing about using rootless containers (with podman and toolbox) is that the root user inside the container has no privileges outside the container.
The user id for the normal user is your real UID (probably 1000, but the root UID will be 0 from the inside the container and a non-privileged user from outside.
It’s easier to see with an example:
[juanje@xps ~]$ toolbox enter
⬢[juanje@toolbox ~$ id
uid=1000(juanje) gid=1000(juanje) groups=1000(juanje),10(wheel)
⬢[juanje@toolbox ~]$ sudo su -
Welcome to the Toolbox; a container where you can install and run
all your tools.
- Use DNF in the usual manner to install command line tools.
- To create a new tools container, run 'toolbox create'.
For more information, see the documentation.
⬢[root@toolbox ~]# id
uid=0(root) gid=0(root) groups=0(root)
⬢[root@toolbox ~]# sleep 20
And, in another terminal (outside the container):
[juanje@xps ~$ ps axu | grep sleep
100000 810579 0.0 0.0 9560 524 pts/8 S+ 20:26 0:00 sleep 20
juanje 811214 0.0 0.0 216228 708 pts/2 S+ 20:26 0:00 grep --color sleep
As you can see, I run sleep 20 as root from inside the container and with UID 0, but from outside I see the process running by the user 100000.
If I do the same with my normal toolbox’s user:
[juanje@xps ~]$ toolbox enter
⬢[juanje@toolbox ~$ id
uid=1000(juanje) gid=1000(juanje) groups=1000(juanje),10(wheel)
⬢[root@toolbox ~]# sleep 20
And, in another terminal (outside the container):
[juanje@xps ~]$ ps axu | grep sleep
juanje 813987 0.0 0.0 9560 524 pts/8 S+ 20:27 0:00 sleep 20
juanje 814065 0.0 0.0 216228 704 pts/2 S+ 20:27 0:00 grep --color sleep
I hope this help to see the point of using this kind of containers and Toolbox.
Okeiokei. But if you have passwd what you know it is sure working outside container, should be the same inside container? I canon not get in superuser prompt as usually.
Hummmmm… I think the problem could be that the software is trying to create or access to a hardware that is not accessible from inside the container.
Toolbox limits the hardware devices that are accessible from inside the container to avoid security risks. Even with superadmin privileges inside the container you can’t create new devices.
I’m not sure how to workarround this, but I think that I saw solutions using Polkit rules.
Nope. The root user inside the container is not the same at the one outside. They don’t share the password or anything.
You can compare the /etc/passwd files from outside and inside and see that they are different.
Hello @juhafinlandvoaa,
What repo is mythtv in? I will try to run through an install in my toolbox and see if I can get the same issue.
They are not the same? No, who create then sudoer inside. Illuminati. I am sure it is behind this. You could be member of it. How I do no know? Text editor do not launch inside container. MythTV is mythical TV frontend or was it backend or centermidle.
Never mind I found it. Currently installing mythtv as I type. So it went no problem. If this container is not special to you, delete it and the image it is made from using Podman.
So podman ps -a to list all containers on your system, find the toolbox one and delete it by name or ID using podman rm <container name> then the image (use it’s ID from the ps command) podman rmi <imadeID>. Then recreate your container and enter it. I think your local image is messed up.
[Edit] I did have to agree to import keys for the rpmfusion repos. And man that mythtv brings in a whole bunch of dependencies. 483 pkgs!
Woaa. This is not surprise. This is how they monitor us. There is something behind this.
Yeah mythtv is heavy with dependencies. I don’t know about tracking, but it must take up some space, even in a container.
My fellows, or is too much and too friendly. I do not know Anglo sax culture so well. Or in Russia it is Товарищ (Tovarishch) So I learn a lot new things. Password is not the same inside container. How do I know what is it then if never set up one. Also I find out that you can run programs outside container by command. I can then do a script in or inside menu launch to run MythTV inside container. Or there was an other way to ad it to tree. It was told some other stream. It was one reason to use Silverlblue to learn something new. But I do not know why text editor do not launch inside container. It needed to install inside. Is it Gedit by default or Nano? In documentation it so difficult to make bigger picture of the system.
Friends is good enough for me, thank you.
Gedit (the text editor) that gets installed on SIlverblue by default is a flatpak I believe. If you want to install the RPM version inside a toolbox container you can do that, but you don’t really have to. The thing about the toolbox container that is a blessing for most users is that it easily shares the home directory and so the files in your home dir are visible and modifiable both inside and outside of the toolbox container. So you can use the flatpak outside of the container, to modify a file you need to use inside the container, or the other way around, because the user home dir is shared between them.
Another thing to keep in mind about containers, toolbox included, is they are meant to be disposable. You will see some people call them ephemeral, which basically means “lasting for a very short time.” Don’t be afraid to mess up the toolbox container, it really is meant to be broken, so to speak. And as you can see, if it isn’t working, just destroy it and make a new one and continue on with your task. Everything you saved into your home dir from a toolbox will still be there after destroying it, but not the applications you installed inside of the toolbox, they are deleted when it is because they reside inside of the container image.
Okei. But if you want to look passwd file you need to have gedit to there. I test and create an other container and execute dnf install nano and the result is that asks root passwd. It can not be so that it asks for text editor superuser, so this is not normal and there is syntax error. Is it Bugzilla issue? I will look if they have open issue for it.
When you install packages in toolbox containers that dnf would normally need root privileges for (like Gedit or nano), you will be prompted to do so as sudo, but you won’t have to enter a password.
Perhaps, like @juanje mentioned, list the steps you used to create the container, and install software in it. Also, did you delete the image you have on your system like I suggested? If not, whatever issues you had with previous containers based on this image will give you the same results. If you want to solve this, I need more info about the steps you take to get to this point.
[Edit]
Or you could use vi /etc/passwd to view it or edit it. When inside Vim the : gets you a command prompt and q quits. Be sure to do a man vim prior to editing to see how to use it.
Or if all you want is to see whats in it, the simplest is to do the following from the command line of the toolbox terminal cat /etc/passwd. Cat is a handy built in command of the shell for viewing plain text files. And if it scrolls by too fast an you want time to read at your leisure, then you can do cat <filename> | less which will give you paging abilities.
Sorry, @juhafinlandvoaa, when I mention the password file, I actually was thinking about using the command cat for checking the content, as @jakfrost commented.
For checking what I told you I did:
[juanje@xps ~]$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
juanje:x:1000:1000:Juanje Ojeda:/var/home/juanje:/bin/bash
And then:
[juanje@xps ~]$ toolbox enter
⬢[juanje@toolbox ~]$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
systemd-coredump:x:999:997:systemd Core Dumper:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
systemd-resolve:x:193:193:systemd Resolver:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
juanje:x:1000:1000::/var/home/juanje:/bin/bash
As you can see, the files are totally different.
Keep in mind that you could use another version of Fedora for the container (which would have different packages’ versions and configurations) and it’ll still work.
Toolbox let you see your home directory and your user from inside the container, but it’s another system.
When you run the container (with toolbox or podman), you run it with your user and its namespace, but the container image (where the /etc and all the container stuff lives) was created before. That’s why those files are there, even when your user doesn’t have the permissions to modify them or use dnf.
After what you’ve told us, it seems like something is wrong with that container. I’ve been using toolbox a lot lately and it never asks me for the root password.
I’d try to reset your containers (if you don’t have any container or container image you really need) and start over the steps you told us before:
podman system reset -f
toolbox create --container tbs
toolbox enter --container tbs
And then, just try to use sudo, for checking the root password part:
⬢[xxmexx@toolbox xxmexx]$ sudo ls
It should work, if not, maybe it’s time to file a bug at the Toolbox’s issue tracker.