[lxc-users] Unprivileged container strange behaviour

[Ruzsinszky Attila]

Hi,

This is my 1st unprivileged container.

Host is Ubuntu 14.04 64 bit.
Container is Ubuntu 16.04 64 bit. It was created by lxc-create.
LXC version is: 2.0.3.

"nincs csatolva" means in English: not mounted.

rattila@fcubi:~$ lxc-start -F -n lub8
umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/blkio/user/1000.user/c4.session/lxc/lub8
nincs csatolva
   umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpuset/user/1000.user/c4.session/lxc/lub8
nincs csatolva
   umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpu/user/1000.user/c4.session/lxc/lub8
nincs csatolva
umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpuacct/user/1000.user/c4.session/lxc/lub8
nincs csatolva
 umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/devices/user/1000.user/c4.session/lxc/lub8
nincs csatolva
  umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/freezer/user/rattila/1/lxc/lub8
nincs csatolva

umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/hugetlb/user/1000.user/c4.session/lxc/lub8
nincs csatolva
 umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/memory/user/rattila/1/lxc/lub8
nincs csatolva
  umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/perf_event/user/1000.user/c4.session/lxc/lub8
nincs csatolva

umount:
/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/systemd/user/1000.user/c4.session/lxc/lub8
nincs csatolva
   systemd 229 running in system mode. (+PAM +AUDIT
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
+GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization lxc.
Detected architecture x86-64.

Welcome to Ubuntu 16.04.1 LTS!

Set hostname to .
Failed to read AF_UNIX datagram queue length, ignoring: No such file or
directory
Failed to install release agent, ignoring: No such file or directory
Couldn't move remaining userspace processes, ignoring: Invalid argument
[  OK  ] Reached target Encrypted Volumes.
...
[  OK  ] Started Journal Service.
[FAILED] Failed to mount Huge Pages File System.
See 'systemctl status dev-hugepages.mount' for details.
[  OK  ] Started Remount Root and Kernel File Systems.
 Starting Load/Save Random Seed...
...
[FAILED] Failed to start Set console scheme.
See 'systemctl status setvtrgb.service' for details.
[  OK  ] Started getty on tty2-tty6 if dbus and logind are not available.
[FAILED] Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details.
[  OK  ] Reached target Network.
...
(I got the login prompt after 5 mins. because of failed network.)

root@lub8:~# init 0
[  OK  ] Stopped target Timers.
[  OK  ] Reached target Unmount All Filesystems.
...
[  OK  ] Stopped Load/Save Random Seed.
[FAILED] Failed unmounting /dev/null.
[  OK  ] Unmounted /dev/zero.
[  OK  ] Reached target Shutdown.

Broadcast message from systemd-journald@lub8 (Thu 2016-07-28 05:23:35 UTC):

systemd[1]: Caught , dumped core as pid 699.


Broadcast message from systemd-journald@lub8 (Thu 2016-07-28 05:23:35 UTC):

systemd[1]: Freezing execution.

... and it was freezed. Waiting for something.
>From the above "[FAILED] Failed to start Raise network interfaces." is true
because I haven't configured OVS for this container.

Switching off lub8 (finishing the freezing):
rattila@fcubi:~/.local/share/lxc/lub8$ lxc-stop -n lub8
lxc-stop: monitor.c: lxc_monitor_read_fdset: 244 No such file or directory
- client failed to recv (monitord died?) No such file or directory
rattila@fcubi:~/.local/share/lxc/lub8$

Other problem:
>From the config file for lub8:

# Network configuration
lxc.network.type = veth
lxc.network.link = vbr0
lxc.network.veth.pair = veth-lub8
lxc.network.flags = up

There isn't veth-lub8 interface on host. Instead of this there is the
generated Ethernet interface which will be renamed every time when I
(re)start lub8:
vethSIIWU5 Link encap:Ethernet  HWaddr fe:db:7d:ba:17:5a
For OVS config I need permanent interface name!

Can I solve these problems?

TIA,
Ruzsi
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc-create using offline mode

[Ruzsinszky Attila]

Hi,

I think, the mentioned description is wrong.
I checked my cache and the rootfs was unpacked and there isn't anything
from meta.tar.xz.

The good news for me is lxc-create (2.0.3) is working with Squid proxy +
authenticate! ;-)
So I used lxc-create as usual. It was a long process. Much more longer than
copying rootfs.tar.xz.
I hope it is working ...

TIA,
Ruzsi
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Can a container modify the host rtc?

[Stewart Brodie]

Marat Khalili  wrote:

> On 26/07/16 19:58, Stewart Brodie wrote:
> >
> > You won't be able to call those functions from a container not in the
> > initial user namespace, even if you possess CAP_SYS_TIME, because of the
> > way the kernel does its permission checks.

> I wonder if there's there really no workaround for ntpd? Special version
> talking to the host through pipe probably? It is very convenient from
> administration point of view to keep every network service in a separate
> container.

I am aware of two workarounds (apart from obviously just running ntpd in the
host itself)

As you suggest, you could try transporting the system calls through a pipe
to something running on the host.  It could work, but to me, that sounds
awkward and introduces another level of stuff that has to be secured - and
keeping things isolated and as secure as possible is presumably the reason
why you want to run ntpd in a container in the first place!

The workaround I use is to patch the kernel to permit the calls based only
on whether the caller possesses CAP_SYS_TIME.  I can only do that because I
control all the software running on our embedded devices, though.  I would
strongly disrecommend doing that on anything where you don't control the
entire machine.


-- 
Stewart Brodie
Senior Software Engineer
Espial UK
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Can a container modify the host rtc?

[Marat Khalili]

On 26/07/16 19:58, Stewart Brodie wrote:


You won't be able to call those functions from a container not in the
initial user namespace, even if you possess CAP_SYS_TIME, because of the way
the kernel does its permission checks.
I wonder if there's there really no workaround for ntpd? Special version 
talking to the host through pipe probably? It is very convenient from 
administration point of view to keep every network service in a separate 
container.


--

With Best Regards,
Marat Khalili
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users