LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Containers
User Name
Password
Linux - Containers This forum is for the discussion of all topics relating to Linux containers. Docker, LXC, LXD, runC, containerd, CoreOS, Kubernetes, Mesos, rkt, and all other Linux container platforms are welcome.

Notices


Reply
  Search this Thread
Old 02-22-2018, 04:14 PM   #31
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,891
Blog Entries: 4

Rep: Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121

root is a special case with containers.

Processes which are running in a containerized environment need to have their own personal perspective of what "user-ids" are. Containers handle this by mapping the user-ids that are perceived by the container to the actual user-ids of the host. Obviously, processes from time to time need to switch to a uid=0 context, and to then appear to(!) exercise super-powers within their container.

The question is: "does the host see 'root?'" Do the powers of a "super-user" within a container therefore extend to the host?

If the container is "non-privileged," as it certainly always should be, a process in a container can believe that it is "root" ... when, to the Linux host, it actually isn't. Linux will dutifully report to the process that it has uid=0. Linux will – up to a point – maintain the illusion of "rootliness." But its actual user-id, as seen by the host, might be 123456. (This arbitrary but non-zero value is unknown to it.) In reality, the process cannot exercise root privileges upon the host. But it is king of its little world.

If the container is "privileged," then its user-id really is zero, even on the host.

For obvious reasons, I counsel that a container should n-e-v-e-r be privileged. If you need to do something on the host which actually requires root privileges on the host, do it outside of the container. You can see the mapping that the container cannot see, so you can arrange things to look right when viewed from the container's perspective.

Last edited by sundialsvcs; 02-22-2018 at 04:34 PM.
 
1 members found this post helpful.
Old 02-22-2018, 04:44 PM   #32
simosx
Member
 
Registered: Jul 2005
Posts: 46

Rep: Reputation: 7
Quote:
Originally Posted by sundialsvcs View Post
For obvious reasons, I counsel that a container should n-e-v-e-r be privileged. If you need to do something on the host which actually requires root privileges on the host, do it outside of the container. You can see the mapping that the container cannot see, so you can arrange things to look right when viewed from the container's perspective.
To check whether a LXD container is privileged, run

Quote:
lxc config get guiapps security.privileged
By default, LXD containers are not privileged. You have to set the flag security.privileged in order for them to be such.
 
1 members found this post helpful.
Old Yesterday, 07:50 AM   #33
Rosika
Member
 
Registered: Apr 2017
Distribution: Lubuntu 64 bit
Posts: 71

Original Poster
Rep: Reputation: Disabled
Hi simosx and sundialsvcs,

thank you so much for the explanation.

In the meantime I got teamviewer running within the container, thanks to simosī great tutorial.
As far as the user-id of processes is concerned I have another question though:

Running "ps -ef" in the host gives me amongst other information the following results:
Code:
root      2795     1  1 13:07 ?        00:00:23 /usr/bin/lxd --group lxd --logfile=/var/log/lxd/lxd.log
lxd       2956     1  0 13:07 ?        00:00:00 dnsmasq --strict-order --bind-interfaces --pid-file=/var/lib/lxd/networks/lxdbr0/dnsmasq.pid --e
rosika    3629  2361  4 13:15 ?        00:00:48 terminology
rosika    3633  3629  0 13:15 pts/1    00:00:00 /usr/bin/fish
root      3747     2  0 13:16 ?        00:00:00 [kworker/u16:2]
root      4332   905  0 13:19 ?        00:00:00 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-ens33.pid
root      4705     1  0 13:21 ?        00:00:00 [lxc monitor] /var/lib/lxd/containers guiapps
231072    4726  4705  0 13:21 ?        00:00:00 /sbin/init
231072    4830  4726  0 13:21 ?        00:00:00 /lib/systemd/systemd-journald
231072    4839  4726  0 13:21 ?        00:00:00 /lib/systemd/systemd-udevd
root      4921     2  0 13:21 ?        00:00:00 [kworker/0:5]
231072    5208  4726  0 13:22 ?        00:00:00 /sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /v
231072    5317  4726  0 13:22 ?        00:00:00 /lib/systemd/systemd-logind
231072    5329  4726  0 13:22 ?        00:00:00 /usr/sbin/cron -f
231179    5332  4726  0 13:22 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
231073    5363  4726  0 13:22 ?        00:00:00 /usr/sbin/atd -f
231176    5364  4726  0 13:22 ?        00:00:00 /usr/sbin/rsyslogd -n
231072    5367  4726  0 13:22 ?        00:00:00 /usr/lib/accountsservice/accounts-daemon
231072    5381  4726  0 13:22 ?        00:00:00 /usr/sbin/sshd -D
231072    5393  4726  0 13:22 ?        00:00:00 /usr/lib/snapd/snapd
root      5428     2  0 13:22 ?        00:00:00 [iscsi_eh]
231072    5509  4726  0 13:22 pts/2    00:00:00 /bin/login --
231072    5566  4726  0 13:22 ?        00:00:00 /usr/lib/policykit-1/polkitd --no-debug
rosika    6164  3633  0 13:23 pts/1    00:00:00 lxc console guiapps
root      6169  2795  0 13:23 ?        00:00:00 /usr/bin/lxd forkconsole guiapps /var/lib/lxd/containers /var/log/lxd/guiapps/lxc.conf tty=0 esc
rosika    6211  4726  0 13:23 ?        00:00:00 /lib/systemd/systemd --user
rosika    6221  6211  0 13:23 ?        00:00:00 (sd-pam)
rosika    6230  5509  0 13:23 pts/2    00:00:00 -bash
rosika    6256  6230  0 13:23 pts/2    00:00:00 fish
rosika    6386  2361  4 13:25 ?        00:00:23 terminology
rosika    6390  6386  0 13:25 pts/4    00:00:00 /usr/bin/fish
root      6646     2  0 13:28 ?        00:00:00 [kworker/u16:0]
root      6650     2  0 13:28 ?        00:00:00 [kworker/u16:3]
rosika    6799  6256  1 13:33 pts/2    00:00:00 c:\TeamViewer\TeamViewer.exe -n
rosika    6930  4726  0 13:33 ?        00:00:00 /home/ubuntu/alte_version_teamviewer/teamviewer/tv_bin/wine/bin/wineserver
rosika    6932  6799  0 13:33 pts/2    00:00:00 /home/ubuntu/alte_version_teamviewer/teamviewer/tv_bin/teamviewerd -n -f
rosika    6965  4726  0 13:33 ?        00:00:00 C:\windows\system32\services.exe
rosika    6970  4726  0 13:33 ?        00:00:00 C:\windows\system32\explorer.exe /desktop
rosika    6976  6799  0 13:33 pts/2    00:00:00 [TeamViewer.exe] <defunct>
rosika    6977  6799  0 13:33 pts/2    00:00:00 /home/ubuntu/alte_version_teamviewer/teamviewer//tv_bin/TVGuiSlave.32 19 6
rosika    6978  6799  0 13:33 pts/2    00:00:00 /home/ubuntu/alte_version_teamviewer/teamviewer//tv_bin/TVGuiDelegate 19 6
root      7122     2  0 13:33 ?        00:00:00 [kworker/0:1]
rosika    7130  6390  0 13:34 pts/4    00:00:00 ps -ef
So I see "rosika" as user-id for "teamviewer" (which is running in the container). Is this right?
Quote:
If the container is "privileged," then its user-id really is zero, even on the host.
O.K., at least the user-id isnīt zero. Thatīs good. But is it alright that it is "rosika". I mean thus I can kill the process from the host (not only from within the container).
Or is it just due to the fact that itīs a GUI-based application (Mapping the user ID ......)

Greetings.
Rosika
 
Old Yesterday, 08:24 AM   #34
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,891
Blog Entries: 4

Rep: Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121
The user-id's 231xxx are most-likely those of the container occupants.

Containers use a mapping-table to map the user-ids seen by the container (including uid=0) into the actual ones known to the host. Container occupants do not know what the mapping is. And you'd need to look in the same place to see if any of them are mapped to rosika.

Also – Wine is a bit of a special case within a containerized environment because it has to have access to the host's X-server. "Google it" for more details.

Yes, because the container processes are, in fact, "Linux processes," the host can kill them. But I suggest that you do it within the appropriate container environment. You don't want to do something that might break the illusion . . .

Last edited by sundialsvcs; Yesterday at 08:26 AM.
 
1 members found this post helpful.
Old Yesterday, 09:34 AM   #35
Rosika
Member
 
Registered: Apr 2017
Distribution: Lubuntu 64 bit
Posts: 71

Original Poster
Rep: Reputation: Disabled
Hi sundialsvcs,

tnx a lot.
Info: I forgot to mention: "lxc config get guiapps security.privileged" gave me no output whatsoever. Thus I assume everything is alright and Iīm running an unprivileged container.

Quote:
Yes, because the container processes are, in fact, "Linux processes," the host can kill them. But I suggest that you do it within the appropriate container environment. You don't want to do something that might break the illusion . . .
Well, I did it just once in order to make a correct statement here. Hope it didnīt hurt too much. But thanks for your suggestion.

Yet thereīs still one thing that puzzles me:

When logging into my container by using the command lxc console guiapps I cannot make use of top.
I get the normal display of processes but it more or less stops working immediately. Furthermore it says:
Quote:
Unknown command - try 'h' for help
I have no idea why that is.
Itīs a bit of a puzzler given the fact that when running the container with lxc exec guiapps -- sudo --login --user ubuntu
top works as it should! With no weird behaviour whatsoever.
And itīs similar with htop. This one at least seems to work, but when closing with CTRL+c the terminal shows
Code:
[?64;1;2;6;9;15;18;21;22c
Thatīs also the case with top.
Do you have any idea why (h)top is beahving in such a way and what I could do about it?

Greetings.
Rosika
 
Old Yesterday, 10:00 AM   #36
simosx
Member
 
Registered: Jul 2005
Posts: 46

Rep: Reputation: 7
Hi Rosika and sundialsvcs,

The instructions at https://blog.simos.info/how-to-run-g...buntu-desktop/
have a step that does userid mapping for your non-root user from the host to the container.
It is the part with title Mapping the user ID of the host to the container (PREREQUISITE).

In other words, the processes of the container's non-root user account can be affected by the host's non-root user account. For example, your host's non-root user account can kill a GUI process running in the container.
However, as far as I understand, the process that launched in the container does not have access to the host's filesystem.
The container is not privileged, but there is a hole to enable running GUI apps with graphics acceleration.

The alternative would be to use a separate graphics-accelerated X server like Xephyr, and send the container's output there.
I have not tried this.

Regarding top and htop, they both work for me on the guiapps container and also a vanilla container.
I tried with both gnome-terminal and xterm (of course running these terminal emulators on the host).
 
Old Yesterday, 10:32 AM   #37
Rosika
Member
 
Registered: Apr 2017
Distribution: Lubuntu 64 bit
Posts: 71

Original Poster
Rep: Reputation: Disabled
Hi Simos,

tnx again.
Quote:
It is the part with title Mapping the user ID of the host to the container (PREREQUISITE).
Yes, I followed your instructions precisely. I just wanted to make sure that everythingīs running o.k.
And it really seems to do do.

As far as (h)top is concerned you inspired me to test xterm.
I installed it in the guiapps-container and upon starting it opened a new window (xterminal). I think thatīs due to the fact that we got graphics-accelerated GUI apps running in the container.

And now it worked. Top and htop are both running without complaint even when starting the container with "lxc console guiapps"!
No idea why I couldnīt get it working any other way. Yet Iīm very pleased with that workaround.

Thanks a lot for your help.
And a big thank you to all the other helpers too.

Greetings.
Rosika
 
Old Yesterday, 12:44 PM   #38
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,891
Blog Entries: 4

Rep: Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121Reputation: 3121
Quote:
Originally Posted by simosx View Post
In other words, the processes of the container's non-root user account can be affected by the host's non-root user account. For example, your host's non-root user account can kill a GUI process running in the container.
However, as far as I understand, the process that launched in the container does not have access to the host's filesystem.
The container is not privileged, but there is a hole to enable running GUI apps with graphics acceleration.
The user-ids seen by the container occupant are specific to the container's environment and the container occupant thinks that he has control of them. What he does not know is that they are being mapped to host-side user-ids. (Ditto group-ids.) You determine the mapping when you set up the container. Yes, other processes which are not running with the container's rose-colored-glasses on can also see those processes ... as they actually are.

You also determine – chroot-jail style – what filesystem topology it is able to see. You can also set strict limits on what resources it may consume.

When a "container occupant" process is dispatched by the host, the entire set of kernel-settings that implements these various illusions is put in place for that process every time it runs. Other processes running on the same machine might not have these illusions put in front of their eyes. (Or, they may have a different set of illusions.) But, conceptually, "a container" is: "a cleverly-crafted and efficient illusion." The occupants believe that they know what the real world looks like, but they are totally wrong. (And, they don't care. It's good enough for them.)

Last edited by sundialsvcs; Yesterday at 12:49 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: A history of low-level Linux container runtimes LXer Syndicated Linux News 0 01-31-2018 11:27 PM
linux container host os and container os question jzoudavy Linux - Newbie 1 09-01-2015 06:21 AM
LXer: Linux Namespaces: Powerful Isolation & OS Level Virtualization LXer Syndicated Linux News 0 11-23-2014 10:12 PM
Question about Linux level 1/Level 2 jobs inara72 Linux - Newbie 2 04-09-2008 09:14 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Containers

All times are GMT -5. The time now is 05:38 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration