[lxc-users] LXD Based Container For Desktop Applications - Some Success - Help
rob e
redgerhoo at yahoo.com.au
Thu Jul 21 08:18:29 UTC 2016
I'm trying to use an LXD based container to run desktop applications on
my standard desktop, in much the same way as this
https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
So far I can run an application in a Xephyr screen (essentially an X
"subscreen") but not on the host desktop (ultimate aim)
For a Xephyr screen
1) Install Xephyr
2) run Xephyr with "Xephyr -a -br -noreset -name xephyr_screen_101
-title Browse_Danger -screen 1800x1080 :101"
3) log into the container and run the program, directing output to
display 101 ie.
a) lxc exec <container-name> bash
b) DISPLAY=:101 firefox
4) Firefox will duly appear on the Xephyr screen
To run this from outside the container
1) Create shell program inside the container, containing just the
command in 3b ie.
#!/bin/bash
DISPLAY=:101 firefox
2) Make the program executable ie. chmod ug+x <shell-program-above> and
possibly change ownership
2) Execute with
lxc exec <container-name> su <user name> -- <shell-program-above>
The minimum config required to make this work seems to be
withname: <container-name>
profiles:
- default
config:
raw.lxc: lxc.aa_profile=lxc-container-default-with-mounting
devices:
root:
path: /
type: disk
x11-unix:
path: /tmp/.X11-unix
source: /tmp/.X11-unix
type: disk
ephemeral: false
by adding a few more mounts we can get a full desktop for user = <user>
to run in Xephyr eg.
devices:
dri:
path: /dev/dri
source: /dev/dri
type: disk
iceauthority-<user>:
path: /home/<user>/.ICEauthority
source: /home/<user>/.ICEauthority
type: disk
root:
path: /
type: disk
x11-unix:
path: /tmp/.X11-unix
source: /tmp/.X11-unix
type: disk
xauthority-<user>:
path: /home/<user>/.Xauthority
source: /home/<user>/.Xauthority
type: disk
ephemeral: false
Obviously we needed to have added <user> first and ensure the home
directory was created (should be created when using "adduser") and then
run the desktop whilst logged in as <user>
No matter what I do I cannot get a program to display on the host screen
eg. DISPLAY=:0 firefox. This return an error message
$ DISPLAY=:0 firefox
No protocol specified
Failed to connect to Mir: Failed to connect to server socket: No
such file or directory
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0
These messages turn up in the host dmesg ... but I'm a bit suspicious of
the apparmor messages, they may be red herrings (should I be?)
* 508499.335953] audit: type=1400 audit(1469067007.731:3225):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lxd-xenial-browse-danger-test_</var/lib/lxd>" pid=29368
comm="apparmor_parser"
* [508499.342613] device vethO9YPDN entered promiscuous mode
* [508499.342650] IPv6: ADDRCONF(NETDEV_UP): vethO9YPDN: link is not ready
* [508499.385405] eth0: renamed from vethE393S7
* [508499.408826] IPv6: ADDRCONF(NETDEV_CHANGE): vethO9YPDN: link
becomes ready
* [508499.408877] lxcbr0: port 4(vethO9YPDN) entered forwarding state
* [508499.408886] lxcbr0: port 4(vethO9YPDN) entered forwarding state
* [508499.438414] audit: type=1400 audit(1469067007.835:3226):
apparmor="DENIED" operation="mount" info="failed type match"
error=-13 profile="lxc-container-default-with-mounting"
name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd"
fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
* [508499.438529] audit: type=1400 audit(1469067007.835:3227):
apparmor="DENIED" operation="mount" info="failed type match"
error=-13 profile="lxc-container-default-with-mounting"
name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd"
fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
* [508514.445340] lxcbr0: port 4(vethO9YPDN) entered forwarding state
and from the host Syslog
* Jul 21 12:10:07 virt-host kernel: [508499.438414] audit: type=1400
audit(1469067007.835:3226): apparmor="DENIED" operation="mount"
info="failed type match" error=-13
profile="lxc-container-default-with-mounting"
name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd"
fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
* Jul 21 12:10:07 virt-host kernel: [508499.438529] audit: type=1400
audit(1469067007.835:3227): apparmor="DENIED" operation="mount"
info="failed type match" error=-13
profile="lxc-container-default-with-mounting"
name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd"
fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
If I then change the apparmor profile to unconfined and re-run, I see
the following in the host dmesg
* [508796.382044] audit: type=1400 audit(1469067304.766:3230):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/ld.so.preload" pid=5259 comm="cupsd" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0
* [508796.395527] audit: type=1400 audit(1469067304.782:3231):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/ld.so.preload" pid=5266 comm="cups-exec"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
* [508796.395578] audit: type=1400 audit(1469067304.782:3232):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/ld.so.preload" pid=5265 comm="cups-exec"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
* [508796.395778] audit: type=1400 audit(1469067304.782:3233):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/ld.so.preload" pid=5265 comm="dbus" requested_mask="r"
denied_mask="r" fsuid=7 ouid=0
* [508796.398616] audit: type=1400 audit(1469067304.782:3234):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/ld.so.preload" pid=5266 comm="dbus" requested_mask="r"
denied_mask="r" fsuid=7 ouid=0
It's worth noting that the legacy LXC approach outlined in the first
link above still works on this host (so I have a legacy style lxc
container which works). The legacy style config is notably different in
its id maps
* lxc.id_map = u 0 100000 1000
* lxc.id_map = g 0 100000 1000
* lxc.id_map = u 1000 1000 1
* lxc.id_map = g 1000 1000 1
* lxc.id_map = u 1001 101001 64535
* lxc.id_map = g 1001 101001 64535
vs the default.
If I try to use the above map, the container won't start. I can use the
following map (created a new profile and then created the test container
using that profile + default) and it will start, but doesn't address
the access problem
* lxc.id_map = u 400000 1000 1
* lxc.id_map = g 400000 1000 1
I also tried adding
* lxc.id_map = u 1001 401001 64535
* lxc.id_map = g 1001 401001 64535
But that didn't help and the 1000 1000 mapping prevented the container
from starting
It seems odd that Xephyr screens are painted ok but the host screen :0
isn't .... And if it's an apparmor problem, how come "unconfined" is
confining it ?
DOES ANYONE HAVE ANY INSIGHTS SUGGESTIONS ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160721/d6fe6f8f/attachment.html>
More information about the lxc-users
mailing list