Re: [lxc-users] [Fwd: Re: unprivileged Debian Buster container on Debian Buster host fail to start: no cgroups, no controllers]

[Xavier Gendre]

Sorry, I don't understand why it doesn't work... Same config is 
successful with my buster host.


Did you try it on a fresh buster install? Did you tweak things around?

Xavier

Le 17/06/2019 à 18:47, Lukas Pirl a écrit :

Ping… no ideas on this?

 Forwarded Message 
From: Lukas Pirl 
To: lxc-users@lists.linuxcontainers.org
Subject: Re: [lxc-users] unprivileged Debian Buster container on Debian Buster
host fail to start: no cgroups, no controllers
Date: Wed, 29 May 2019 00:11:29 +0200


On Tue, 2019-05-28 21:50 +0200, Xavier Gendre wrote as excerpted:

Hello Lukas,

unprivileged buster containers on a buster host run like a charm. Your
config includes a lot of stuff that are not suited for an unprivileged
container (apparmor, ...). First, you should try with a simpler
configuration file as the following one.

---%<--%<--%<---
lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536
lxc.net.0.type = empty
--->%-->%-->%---

Then,
lxc-create -n test -f config.file -t download -- --dist debian --release
buster --arch amd64
lxc-start -n test


Thanks for your reply, Xavier. No luck. This is what I have/see now:

$ egrep -v '^#' test.config
lxc.net.0.type = empty
lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536

$ lxc-create -n test -f test.config -t download -- --dist debian \
   --release buster --arch amd64
Permission denied - Failed to open ttyPermission denied - Failed to open
ttyPermission denied - Failed to open ttycat: /proc/1/uid_map: No such file
or
directory
Using image from local cache
Unpacking the rootfs

---
You just created a Debian buster amd64 (20190509_05:24) container.

To enable SSH, run: apt install openssh-server
No default root or user password are set by LXC.

$ ll /dev/tty
crw-rw-rw- 1 root tty 5, 0 2019-05-28 23:41:32 /dev/tty /dev/tty[0-9]*
crw--w 1 root tty 4, 0 2019-05-28 11:15:54 /dev/tty0
… # all tty have the same permissions

$

Should the user ``lxc`` be in the group ``tty``?

Apparently, ``lxc-create`` queries ``/proc/1/{u,g}id_map`` which it is not
allowed to (proc mounted with hidepid=2) instead of
``/proc/self/{u,g}id_map``, no?

$ cat /proc/self/{u,g}id_map
  0  0 4294967295
  0  0 4294967295

$ egrep -v '^#' test/config
lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536
lxc.rootfs.path = dir:/home/lxc/test/rootfs
lxc.uts.name = test
lxc.net.0.type = empty

$ lxc-start -n test -F
Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied
[!!] Failed to mount API filesystems.
Exiting PID 1...
$

Okay, let's first try to make ``/dev/tty`` read-writable for the user
``lxc``
(just for testing, ignoring if that is appropriate or not):

$ chmod a+rw /dev/tty /dev/tty[0-9]*
$ ll /dev/tty /dev/tty[0-9]*
crw-rw-rw- 1 root tty 5,  0 2019-05-28 23:41:32 /dev/tty
crw-rw-rw- 1 root tty 4,  0 2019-05-28 11:15:54 /dev/tty0
…

$ lxc-destroy -n test
$ lxc-create -n test -f test.config -t download -- --dist debian --release
buster --arch amd64
Permission denied - Failed to open ttyPermission denied - Failed to open
ttyPermission denied - Failed to open ttycat: /proc/1/uid_map: No such file
or
directory
Using image from local cache
Unpacking the rootfs

---
You just created a Debian buster amd64 (20190509_05:24) container.

To enable SSH, run: apt install openssh-server
No default root or user password are set by LXC.
$

The error when starting persist as above.

Hm, okay let's mount ``/proc`` with ``hidepid=0``. Destroy and create: The
tty
error persists, the cat error is gone. Start: errors persist as above.

Alright, last thing, let's try to remove the includes from the config file
(changes until now still in place):

$ egrep -v '^#' test/config
lxc.arch = linux64
lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536
lxc.rootfs.path = dir:/home/lxc/test/rootfs
lxc.uts.name = test
lxc.net.0.type = empty

$ lxc-start -n test -F
Failed to lookup module alias 'autofs4': Function not implemented
Failed to lookup module alias 'unix': Function not implemented
Failed to mount sysfs at /sys: Operation not permitted
Failed to mount proc at /proc: Operation not permitted
Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied
[!!] Failed to mount API filesystems.
Exiting PID 1...

My lxc.conf does not include anything exotic as well:

$ egrep -v '^#' .config/lxc/lxc.conf
lxc.lxcpath = /home/lxc

Any ideas?

Cheers,

Lukas


Le 28/05/2019 à 15:54, Lukas Pirl a écrit :

Dear all,

first, thanks for the friendly and supportive help you all provide in
issue
trackers, on mailing lists, etc. – it is very helpful to find all this
online.

However, I struggle to run unprivileged (Debian Buster) containers (on a
Debian Buster host). LXC does not seem to mount the cgroup mount points
for
the container, thus the container's systemd tries to mount t

Re: [lxc-users] unprivileged Debian Buster container on Debian Buster host fail to start: no cgroups, no controllers

[Xavier Gendre]

Hello Lukas,

unprivileged buster containers on a buster host run like a charm. Your 
config includes a lot of stuff that are not suited for an unprivileged 
container (apparmor, ...). First, you should try with a simpler 
configuration file as the following one.


---%<--%<--%<---
lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536
lxc.net.0.type = empty
--->%-->%-->%---

Then,
lxc-create -n test -f config.file -t download -- --dist debian --release 
buster --arch amd64

lxc-start -n test

Regards,
Xavier

Le 28/05/2019 à 15:54, Lukas Pirl a écrit :

Dear all,

first, thanks for the friendly and supportive help you all provide in issue
trackers, on mailing lists, etc. – it is very helpful to find all this online.

However, I struggle to run unprivileged (Debian Buster) containers (on a
Debian Buster host). LXC does not seem to mount the cgroup mount points for
the container, thus the container's systemd tries to mount those and fails due
to insufficient permissions.

The log reports no writable cgroup hierarchies and no available controllers –
could there be a common cause?

I decided not to open an issue so far, since I am not sure if it is just me
being incompetent here or if there is an actual issue. If we find an actual
issue, I'll of course move this to the issue tracker.

Please find all the configuration dumps and logs below.

IIRC, I tried to run the script as provided in
   https://github.com/lxc/lxc/issues/1998#issuecomment-353241255
without success and various other things. However, I am unsure how the
available information can be applied since a few things changed in LXC 3, no?
And systemd seems to a moving target as well.

Also, I work on an automation using Ansible to set up a host which can run
unprivileged containers. This will be publicly available once everything
works.

Cheers,

Lukas



symptom
---

``lxc-start -n rproxy -l TRACE -o lxc.log -F``::

   Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied
   [!!] Failed to mount API filesystems.
   Exiting PID 1...

``lxc.log``:
https://bin.privacytools.io/?28c8377e545ce6a9#9I2a28JuaYf7yHDNIxtxCQxox6LvTrxT4l4scUDgQNc=

host details


* ``cat /etc/debian_version``: 10.0
* ``lxc-start --version``: 3.0.3
* ``lxc-checkconfig``::

 Kernel configuration not found at /proc/config.gz; searching...
 Kernel configuration found at /boot/config-4.19.0-5-amd64
 --- Namespaces ---
 Namespaces: enabled
 Utsname namespace: enabled
 Ipc namespace: enabled
 Pid namespace: enabled
 User namespace: enabled
 Network namespace: enabled

 --- Control groups ---
 Cgroups: enabled

 Cgroup v1 mount points:
 /sys/fs/cgroup/systemd
 /sys/fs/cgroup/memory
 /sys/fs/cgroup/cpuset
 /sys/fs/cgroup/cpu,cpuacct
 /sys/fs/cgroup/blkio
 /sys/fs/cgroup/net_cls,net_prio
 /sys/fs/cgroup/perf_event
 /sys/fs/cgroup/rdma
 /sys/fs/cgroup/freezer
 /sys/fs/cgroup/devices
 /sys/fs/cgroup/pids

 Cgroup v2 mount points:
 /sys/fs/cgroup/unified

 Cgroup v1 clone_children flag: enabled
 Cgroup device: enabled
 Cgroup sched: enabled
 Cgroup cpu account: enabled
 Cgroup memory controller: enabled
 Cgroup cpuset: enabled

 --- Misc ---
 Veth pair device: enabled, not loaded
 Macvlan: enabled, not loaded
 Vlan: enabled, not loaded
 Bridges: enabled, loaded
 Advanced netfilter: enabled, loaded
 CONFIG_NF_NAT_IPV4: enabled, loaded
 CONFIG_NF_NAT_IPV6: enabled, loaded
 CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded
 CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded
 CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, not loaded
 CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, loaded
 FUSE (for use with lxcfs): enabled, loaded

 --- Checkpoint/Restore ---
 checkpoint restore: enabled
 CONFIG_FHANDLE: enabled
 CONFIG_EVENTFD: enabled
 CONFIG_EPOLL: enabled
 CONFIG_UNIX_DIAG: enabled
 CONFIG_INET_DIAG: enabled
 CONFIG_PACKET_DIAG: enabled
 CONFIG_NETLINK_DIAG: enabled
 File capabilities:

 Note : Before booting a new kernel, you can check its configuration
 usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

* ``uname -a``: Linux hive 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3
   (2019-05-15) x86_64 GNU/Linux

* ``cat /proc/self/cgroup``::

 11:pids:/user.slice/user-1000.slice/session-4.scope
 10:devices:/user.slice
 9:freezer:/user/lxc/0
 8:rdma:/
 7:perf_event:/
 6:net_cls,net_prio:/
 5:blkio:/user.slice
 4:cpu,cpuacct:/user/lxc/0
 3:cpuset:/user/lxc/0
 2:memory:/user/lxc/0
 1:name=systemd:/user/lxc/0
 0::/user.slice/user-1000.slice/session-4.scope/user/lxc/0

* ``cat /proc/self/mountinfo``::

   20 25 0:19 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
   21 25 0:4 / /proc 

Re: [lxc-users] How can a non-root user assign unique UID/GID range for LXC unprivileged containers ??

[Xavier Gendre]

Hi,

Le 21/08/2018 à 13:39, Dirk Geschke a écrit :

can you check the directory permissions for

/home/oxpd/.local/share/lxc/uidranges


As Dirk said, your problem could be related to permissions of the rootfs 
itself and not to subordinate ids.


Le 21/08/2018 à 12:07, Yasoda Padala a écrit :
> in 1st container (cont1) config,
>   lxc.id_map = u 0 10 1000
> lxc.id_map = g 0 10 1000
>   &
> and in 2nd container (cont2) config:
> lxc.id_map = u 0 101500 1000
> lxc.id_map = g 0 101500 1000
>
>   get the same error

On my side, these configurations work fine together and the two 
containers (created by a non-root user with template "download" and 
distribution debian stretch amd64 for my tests) start without a trouble. 
The rootfs of the containers c1 and c2 belongs to subuid 10 and 
101500, respectively, just as you want.


Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] How can a non-root user assign unique UID/GID range for LXC unprivileged containers ??

[Xavier Gendre]

Hi Yasoda,

only 10 ids is a bit short for a container. You should increase this 
number to cover at least the system ids 0-999. Depending on the 
distribution you run in your containers, you can be sharper and only 
involve the needed ids but they all have to be covered.


Xavier

Le 20/08/2018 à 09:13, Yasoda Padala a écrit :

Hi All,
can someone please help me with the above query..

Thans & Regards,
Yasoda

On Fri, Aug 17, 2018 at 9:34 AM Yasoda Padala > wrote:


Hi All,
I have created non-root user on my Ubuntu (16.04) machine who
creates unprivileged LXC containers.
My user's uid/gid on the host is 1000.
and below are the entries in /etc/subuid &  /etc/subgid files

/etc/subuid:
lxcuser:10 65536

/etc/subgid:
lxcuser:10:65536

My requirement is for each LXC unprivileged container, I should be
able to pick a UID/GID range.
For instance, I have created two LXC containers cont1 and cont2
in cont1 config, I have added the below id mappings
lxc.id_map = u 0 10 10
lxc.id_map = g 0 10 10

and in con2 config file, I have added the below id mappings
lxc.id_map = u 0 100020 10
lxc.id_map = g 0 100020 10

cont1 starts successfullly but cont2 gives the below error while
starting the container

lxc-start 20180817035100.984 ERROR lxc_conf -
conf.c:mount_rootfs:798 - Permission denied - Failed to get real
path for "/home/oxpd/.local/share/lxc/uidranges/rootfs".

   lxc-start 20180817035100.984 ERROR    lxc_conf -
conf.c:setup_rootfs:1220 - Failed to mount rootfs
"/home/oxpd/.local/share/lxc/uidranges/rootfs" onto
"/usr/lib/x86_64-linux-gnu/lxc" with options "(null)".

   lxc-start 20180817035100.984 ERROR    lxc_conf -
conf.c:do_rootfs_setup:3899 - failed to setup rootfs for 'uidranges'

   lxc-start 20180817035100.984 ERROR    lxc_conf -
conf.c:lxc_setup:3981 - Error setting up rootfs mount after spawn

   lxc-start 20180817035100.984 ERROR    lxc_start -
start.c:do_start:811 - Failed to setup container "uidranges".

   lxc-start 20180817035100.984 ERROR    lxc_sync -
sync.c:__sync_wait:57 - An error occurred in another process
(expected sequence number 3)

   lxc-start 20180817035100.985 ERROR    lxc_start -
start.c:__lxc_start:1358 - Failed to spawn container "uidranges".

   lxc-start 20180817035106.524 ERROR    lxc_start_ui -
tools/lxc_start.c:main:366 - The container failed to start.

   lxc-start 20180817035106.525 ERROR    lxc_start_ui -
tools/lxc_start.c:main:368 - To get more details, run the container
in foreground mode.

   lxc-start 20180817035106.525 ERROR    lxc_start_ui -
tools/lxc_start.c:main:370 - Additional information can be obtained
by setting the --logfile and --logpriority options.

My understanding is lxcuser who has been assigned with id range of
10-165536 can assign a distinct subuid/gid  ranges for each
container spawned by lxcuser.

is my understanding correct ?? I am not finding any reference
documents for custom user mappings for LXC unprivileged containers

Any help on this is highly appreciated.



Thanks & Regards,

Yasoda






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



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

Re: [lxc-users] HOWTO: How to run graphics-accelerated GUI apps in LXD containers on your Ubuntu desktop

[Xavier Gendre]

Hi,

> I completed the tutorial on how to run graphics-accelerated GUI apps
> in (local) LXD containers,
> https://blog.simos.info/how-to-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/
> 
> Compared to the previous post, this one has sound and also shows how
> to create a shortcut so that the GUI app can run in a single click,
> from the Launcher.

Thanks Simos for your work!
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Building custom LXC templates

[Xavier Gendre]

Yes but you can run it in a VM where you have superuser privileges. The
goal is simply to obtain the two files meta.tar.xz and rootfs.tar.xz.


Oh, I see. I was under the impression that I would get a template
script, similar to what exists under /usr/share/lxc/templates. Are those
hand-written?


I don't know but you can modify them by hand in order to adapt the 
templates to your needs.



What do you mean by "this [...] builds LXC"?


The "build-image" script appears to clone, configure and make LXC from
some repository, instead of using the system version. This is probably
the right thing to do for CI of LXC itself, but not for downstream users.


Ok, I understand. Yes, this is the way these tools work. I don't really 
care about that because I run all this stuff in a VM just to obtain the 
above files. If the script wants to build some stuff, it is ok for me 
;-) But you are right, there should be some easier way.


Xavier

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

Re: [lxc-users] Building custom LXC templates

[Xavier Gendre]

a) I need superuser privileges to run this? Running this in CI would be
ruled out then, and


Yes but you can run it in a VM where you have superuser privileges. The 
goal is simply to obtain the two files meta.tar.xz and rootfs.tar.xz.



b) this downloads and builds LXC from master?


What do you mean by "this [...] builds LXC"?

Xavier

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

Re: [lxc-users] Building custom LXC templates

[Xavier Gendre]

Hello Lars,


However, I have no idea how to do that. Is it possible to create a
container locally and pack it up to be extracted somewhere else? Would
that even be portable? If so, is there tooling for that? I use
configuration management for everything else already; LXC so far is the
only thing I haven't automated.


You can use the tools provided here:
https://github.com/lxc/lxc-ci

To produce a custom templates, you will have to adapt some file in 
lxc-ci/templates and then run bin/build-image. I did it a lot before to 
get working Debian Jessie containers before lxc 1.1.5 arrived in 
jessie-backports. When you get the custom template and its rootfs, you 
can choose to force the cache to use them or to create a custom template 
server.


Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Can't ssh my lxc instances and no instance console on Horizon

[Xavier Gendre]

Hi,

> I'm unable to ssh into any instance except the CirrOS.

For ssh, did you try to set pam_loginuid.so to "optional" in
/etc/pam.d/sshd in your containers?

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

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

Le 09/01/2016 03:23, Fajar A. Nugraha a écrit :
> Anyway, I wrote this several months ago, should be the easiest way to
> get unpriv jessie on jessie: http://debian-lxc.github.io/
> The repo has lxc-1.1.5 and cgmanager, ported from ubuntu.

I have followed your tutorials and it works perfectly well, thanks
Fajar! This is definitly cleaner than my way and, now, I have a lot to
do to update my stuff ;-) I will add a link to your tutorials in my blog
post to indicate this better way.

A little question, the repositories that you use for lxc and systemd are
maintained with up-to-date packages? Do you plan to maintain it for some
times or is it only experimental?

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

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

Hello Carlos,

> Once you replace systemd with sysvinit in the container, you get it
> booting and starting the services, but you can't login on it (via the
> login prompt) or ssh on it.

I didn't know that, i always use lxc-attach to get a prompt in my
containers and it works like a charm.

> You will get the following error:
> 
> " Cannot make/remove an entry for the specified session "
> 
> This is caused because Debian now requires pam_loginuid for both login
> an sshd
> 
> # grep pam_loginuid  /etc/pam.d/*
> /etc/pam.d/login:sessionrequired pam_loginuid.so
> /etc/pam.d/sshd:sessionrequired pam_loginuid.so
> 
> You have to remove that line from both files to be able to login on the
> container via the login prompt or via ssh

Thanks for that point, i will use it one day if i need to properly login
or ssh into one of my containers.

Xavier

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

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

Hello Fajar,

> Anyway, I wrote this several months ago, should be the easiest way to
> get unpriv jessie on jessie: http://debian-lxc.github.io/
> The repo has lxc-1.1.5 and cgmanager, ported from ubuntu.

I just discover your link and I wonder how I could miss it! Thanks a
lot, it seems that everything is well explained. I will test your
tutorials soon ;-)

Xavier

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

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

Although setting it up was not as straightforward as your tutorial:

- Package "python3-all-dev" currently has dependency issues
(https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1503382,
http://askubuntu.com/a/683604/331398)

   I was able to solve this by adding a time.sleep(120) in
lxc-ci/__init__.py before self.update(), attaching to the new
temporary container while the timer was running and downgrading the
python3-packages (See askubuntu-answer)


I never encounter this problem. What is the version of Ubuntu that you 
are using for building the Jessie image? In my explanations, i use the 
14.04 LTS and everything works.



- cgroups caused some trouble. Setting them with cgmanager/cgm for the
specific user helped (See http://unix.stackexchange.com/a/171478/88252
and http://bit.ly/1jokrFl)
   If anyone knows a good way to make this permanent, let me know!

   Basically it's:

   sudo service cgmanager start
   sudo cgm create all $USER
   sudo cgm chown all $USER $(id -u) $(id -g)
   sudo cgm movepid all $USER $$



If you have to do such things, i think that you try to apply my tutorial 
in a Debian host. It will work but, as you notice, you will have to 
tweak cgroup by hand. On my side, i create the Jessie image in a VM with 
Ubuntu (because there is not such problems with cgroups) and i use this 
image in my Jessie host (where i tweak my cgroups through a custom 
systemd service in order to give ownerships to the unprivileged users).



- "lxc-attach -n $jessiecontainer" does not set the full
$PATH-environment-variable which is quite inconvenient when
unexpected, "export
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
helps


When i attach to my unprivileged Jessie container, PATH is properly set. 
I don't remind me if i did something specific for that...



- The Jessie-template does not include man-db, iputils-ping,
apt-utils, rsyslog - I found it easier to configure the container with
these installed, could be added to the debian.json-file (But they
where probably left out to make the template slimmer)


You can add them in debian.json, this is your custom Jessie image. For 
example, i add rsyslog and vim in such a way. If you want a slim one and 
an enhanced one, you are free to create two images. To use them 
simultaneously in your cache directory, you can use the "variant" option.



But it looks like this is otherwise working quite ok, thanks a lot!


Welcome, happy to help ;-)

Xavier

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

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

and i use this image in my
Jessie host (where i tweak my cgroups through a custom systemd service in
order to give ownerships to the unprivileged users).


Could you maybe also share that custom systemd service configuration?
Then I can continue to sit on my lazy butt and don't have to reinvent
the wheel :-) No, I'm just really busy with a migration right now and
it would be a great help to get this out of the way quickly! I'm not
really up to speed with systemd yet... :-\


Here is the script i run as forking systemd service (i.e. "Type=forking" 
in service file) to start an unprivileged container called 'unpriv' 
which belongs to an user called 'bobby':


<<<
#!/bin/bash

# List of cgroups to chown
SUBSYS="perf_event blkio net_cls,net_prio freezer devices cpu,cpuacct 
cpuset"


# Needed to start unprivileged container
echo 1 > /sys/fs/cgroup/cpuset/cgroup.clone_children

# Create a dedicated cgroup and give it to 'bobby'
for S in $SUBSYS; do
  mkdir -p /sys/fs/cgroup/$S/lxc-bobby
  chown bobby:bobby /sys/fs/cgroup/$S/lxc-bobby
  chown bobby:bobby /sys/fs/cgroup/$S/lxc-bobby/tasks
done

# Clean the cgroup hierarchy
for S in $SUBSYS; do
  if [ -d /sys/fs/cgroup/$S/lxc-bobby/unpriv ]; then
find /sys/fs/cgroup/$S/lxc-bobby/unpriv/ -type d | tac | xargs rmdir
  fi
done

# Start the container
su bobby --shell /bin/bash --command " \
  echo \$\$ >> /sys/fs/cgroup/perf_event/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/blkio/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/net_cls,net_prio/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/freezer/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/devices/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/cpu,cpuacct/lxc-bobby/tasks; \
  echo \$\$ >> /sys/fs/cgroup/cpuset/lxc-bobby/tasks; \
  lxc-start -n unpriv -d"
>>>

Maybe some steps are overkill but it works ;-) Here are some explanations:

* according to Serge Hallyn, the cgroups in SUBSYS are not all properly 
needed but i never success to run my unprivileged containers without all 
of them (i think that it is fixed in next versions but, with Jessie, we 
are stuck to 1.0.6).


* you have to put 1 in clone_children to start unprivileged containers 
(i don't know why this is not set by default in Debian but it is 
correctly set in Ubuntu).


* after creating and chowning the cgroup, i clean it. It is useful when 
you restart the container. Otherwise, it will name the new cgroup 
'unpriv-1', 'unpriv-2', ... The trick with tac is simply to remove all 
the stuff in the right order.


* thus, i add the pid in the tasks files and the unprivileged container 
can start!


Hope that it helps you and your lazy butt ;-)

Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?

[Xavier Gendre]

Le 13/10/2015 11:49, Fajar A. Nugraha a écrit :

On Tue, Oct 13, 2015 at 4:44 PM, Christian Benke  wrote:

On 13 October 2015 at 11:15, Fajar A. Nugraha  wrote:

So bottom line, don't bother unless you're willing to run a
"frakenstein", unsupported distro. Either retry with stretch and hope
it works better, or switch to ubuntu.


Thanks a lot for the detailed explanation Fajar! Looks like I'm just
going to run privileged containers and hope for the best. Turns out,
doing the testing on the right distribution too is essential :-) (I
tried LXC on my Ubuntu Trusty workstation and deemed it working, but
the server is running Debian Jessie)


Yep, trusty is probably the best distro for host lxc right now.
Particularly if you also add ppa:ubuntu-lxc/lxc-stable to get
lxc-1.1.4 and lxcfs.

Privilged containers on jessie should work, although I'd still
recommend using lxc-1.1.x (either compile from source, or port
ubuntu's package recipe) instead of the bundled 1.0.6



You can run unprivileged Jessie container in a Jessie host. The point is 
that the container fails to start mainly because of systemd in the 
Jessie container.


To tackle that problem, i create a custom image of Jessie without 
systemd and it runs perfectly. I give the details to create the image 
and the container in my blog (in french, sorry):


https://www.meseira.fr/blog/post/2015/08/02/unprivileged-jessie-container/

It consists in using the tools of lxc-ci and modifying the script 
devoted to Jessie image to replace systemd by sysvinit. After, you just 
have to set your cache directory to provide the custom Jessie image to 
lxc-create.


Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Autostart Unpriviledged Containers

[Xavier Gendre]

Le 06/10/2015 06:03, Paul Jones a écrit :

Hi.

I'm using Debian Stretch. And I would like to use unpriviledged containers.

It seems by default, there is one cgroup owned by root. In order to
start an unpriviledged container I need to create a new cgroup, chown it
to the unpriviledged user and then move the current tty process into
that cgroup. Then start the container from there.

If this is the case, how will it be possible to autostart containers on
boot?

Or am I going about this all wrong?


Hi Paul,

to start an unprivileged container on boot, you run some steps similar 
to what you describe but in a script that you call through a systemd 
service.


Here are the step i do:
- set clone_children to 1
- create a dedicated cgroup and give it to my user
- start the container

Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Containers start without networking

[Xavier Gendre]

Hello,

I never encounter this problem with my containers. However, you should 
upgrade LXC to a more recent version to see if the problem persists.


According to the version you mention, i assume that you run LXC in a 
Debian Wheezy (oldstable). If you do not plan to upgrade to Debian 
Jessie (stable), you should use the LXC package in the Wheezy backports. 
This version is 1:1.0.6-6+deb8u1~bpo70+1 and is more up-to-date.


Friendly,
Xavier

Le 23/09/2015 08:59, Joris Michaux a écrit :

Hello,

After the first boot of my hosts, the containers are auto-starting
without networking. I have to lxc-stop and lxc-start (without the -d) to
"service networking restart" and all goes right.

LXC version : 0.8.0~rc1-8+deb7

Regards,


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

Re: [lxc-users] Mounting as rw into container

[Xavier Gendre]

Hi,

an easy way is to use lxc.mount.entry with bind in the config file of 
the container. An example could be the following line:


lxc.mount.entry = /path/to/directory/in/host 
path/to/directory/in/container none bind,create=dir 0 0


Note the missing '/' at the beginning of the target path in order to set 
it relatively to the container. To be able to 'rw' in this directory, be 
sure to chown it with the appropriate uid:gid.


Xavier

Le 08/09/2015 21:25, SIVA SUBRAMANIAN.P a écrit :

Hi,
I want to mount some dir as rw into the container, but I'm not able to
do with mount entry as rw in the lxc config file. Any inputs will be
helpful for me.

Regards,
Sivasubramanian


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


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

[lxc-users] Capitole du Libre 2015

[Xavier Gendre]

Hi,

the sequel of this message is in french, sorry for non francophones...

En plus de m'intéresser à LXC et de poster sur cette liste, je fais 
partie de l'association toulousaine Toulibre dont l'objectif et la 
promotion et la diffusion des logiciels libres.


Dans ce cadre, nous organisons chaque année une série de conférences et 
ateliers sur un week-end de novembre. Cet événement s'appelle le 
'Capitole du Libre' et le prochain aura lieu à Toulouse les 21 et 22 
novembre 2015.


Pour plus d'informations sur l'association, il y a le site toulibre.org 
et en ce qui concerne l'événement, c'est sur 2015.capitoledulibre.org. 
Vous pouvez également voir ce qui s'est fait l'an passé sur 
2014.capitoledulibre.org.


Si certaines personnes sur cette liste se trouvent en France à cette 
période (les moyens de l'association ne permettent que la prise en 
charge de trajets nationaux) et qu'elles souhaitent proposer une 
intervention (conférence et/ou atelier), n'hésitez pas!


L'appel à propositions est ouvert jusqu'au 15 septembre à minuit. Tout 
se passe sur la page :

https://2015.capitoledulibre.org/propositions/

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

Re: [lxc-users] Nested container in unpriviledged container

[Xavier Gendre]

Le 18/06/2015 06:35, Serge Hallyn a écrit :

Quoting Xavier Gendre (gendre.rei...@gmail.com):

Le 15/06/2015 17:17, Serge Hallyn a écrit :

Quoting Xavier Gendre (gendre.rei...@gmail.com):

Hi,

i wanted to run a container in an unpriviledged container and i am
glad to succes in doing it. The point is that i am not sure if what
i did is acceptable from the security point of view or not...

Here are the steps i did:

1) create an unpriviledged container (lxc.id_map, ...) called 'test'.

2) mount a tmpfs to /sys/fs/cgroup in 'test' by adding this line in
its config file:

lxc.mount.auto = cgroup:mixed

3) create a basic container called 'p1' with the download template
as root in 'test'.

4) in the host, i chown the cgroup hierarchy of 'test' to give it to
the user id mapped to the id 0 in 'test' (this id is 362144 in my
example),

for T in `ls /sys/fs/cgroup`; do
   chown -R 362144:362144 /sys/fs/cgroup/$T/lxc/test
done

5) succesfully start the container 'p1' in 'test' :-)

I am not an expert with cgroups and i am wondering if i am letting
the devil enters in my home with that...

So, what is your opinion: is it a possible security break or is it safe?


Two things to make this safer

1. only chown the actual directory /sys/fs/cgroup/$T/lxc/test and maybe
its 'tasks' and 'cgroup.procs' files.  That way the container can create
sub-cgroups but cannot raise its own limits.

2. Only do this for the controllers you definately need.  Freezer and
memory for example.  Then set lxc.cgroup.use in /etc/lxc/lxc.conf
(see lxc.system.conf(5)).

-serge


Hello Serge,

thank you for your advices. Indeed, chowning only the directories is
sufficient to start the nested container. I did not have to chown
'tasks' and 'cgroup.procs' in order to simply start it.

Your second point is more obscur for me... For now, i have to chown
all the controllers:

'blkio' 'cpu,cpuacct' 'cpuset' 'devices' 'freezer'
'net_cls,net_prio' 'perf_event'

When you say 'need', it applies to the container 'test' or to 'p1'
in my example?


The child one, p1.  With new enough lxc you should be able to
use only freezer, setting that as lxc.cgroup.use in the
system lxc.conf.


Arf, for now, i am still working with Debian Jessie and LXC 1.0.7. I 
will be able to try your suggestions when more recent version of LXC 
will appear in Debian repositories. Thus, i continue to chown my whole 
list of controllers :-°



If i plan to allow quite general containers to run in
my unpriviledged container, all the controllers should be chowned or
is there some that are definitely not needed?


General containers are fine, it's only if you need the nested containers
to be more finely restricted, i.e. if you simply must be able to
allocated only a subset of test1's cpus or memory.


Ok, thanks for this example, it is clearer for me now.

Thank you for these explanations,
Xavier
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Nested container in unpriviledged container

[Xavier Gendre]

Le 15/06/2015 17:17, Serge Hallyn a écrit :

Quoting Xavier Gendre (gendre.rei...@gmail.com):

Hi,

i wanted to run a container in an unpriviledged container and i am
glad to succes in doing it. The point is that i am not sure if what
i did is acceptable from the security point of view or not...

Here are the steps i did:

1) create an unpriviledged container (lxc.id_map, ...) called 'test'.

2) mount a tmpfs to /sys/fs/cgroup in 'test' by adding this line in
its config file:

lxc.mount.auto = cgroup:mixed

3) create a basic container called 'p1' with the download template
as root in 'test'.

4) in the host, i chown the cgroup hierarchy of 'test' to give it to
the user id mapped to the id 0 in 'test' (this id is 362144 in my
example),

for T in `ls /sys/fs/cgroup`; do
   chown -R 362144:362144 /sys/fs/cgroup/$T/lxc/test
done

5) succesfully start the container 'p1' in 'test' :-)

I am not an expert with cgroups and i am wondering if i am letting
the devil enters in my home with that...

So, what is your opinion: is it a possible security break or is it safe?


Two things to make this safer

1. only chown the actual directory /sys/fs/cgroup/$T/lxc/test and maybe
its 'tasks' and 'cgroup.procs' files.  That way the container can create
sub-cgroups but cannot raise its own limits.

2. Only do this for the controllers you definately need.  Freezer and
memory for example.  Then set lxc.cgroup.use in /etc/lxc/lxc.conf
(see lxc.system.conf(5)).

-serge


Hello Serge,

thank you for your advices. Indeed, chowning only the directories is 
sufficient to start the nested container. I did not have to chown 
'tasks' and 'cgroup.procs' in order to simply start it.


Your second point is more obscur for me... For now, i have to chown all 
the controllers:


'blkio' 'cpu,cpuacct' 'cpuset' 'devices' 'freezer' 'net_cls,net_prio' 
'perf_event'


When you say 'need', it applies to the container 'test' or to 'p1' in my 
example? If i plan to allow quite general containers to run in my 
unpriviledged container, all the controllers should be chowned or is 
there some that are definitely not needed?


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

[lxc-users] Nested container in unpriviledged container

[Xavier Gendre]

Hi,

i wanted to run a container in an unpriviledged container and i am glad 
to succes in doing it. The point is that i am not sure if what i did is 
acceptable from the security point of view or not...


Here are the steps i did:

1) create an unpriviledged container (lxc.id_map, ...) called 'test'.

2) mount a tmpfs to /sys/fs/cgroup in 'test' by adding this line in its 
config file:


lxc.mount.auto = cgroup:mixed

3) create a basic container called 'p1' with the download template as 
root in 'test'.


4) in the host, i chown the cgroup hierarchy of 'test' to give it to the 
user id mapped to the id 0 in 'test' (this id is 362144 in my example),


for T in `ls /sys/fs/cgroup`; do
  chown -R 362144:362144 /sys/fs/cgroup/$T/lxc/test
done

5) succesfully start the container 'p1' in 'test' :-)

I am not an expert with cgroups and i am wondering if i am letting the 
devil enters in my home with that...


So, what is your opinion: is it a possible security break or is it safe?

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

Re: [lxc-users] Is there a guide to LXC ipv6 configuration

[Xavier Gendre]

Hi Brian,

the IPv4 magic in LXC comes from the use of dnsmasq. According to what i 
have read, you can configure dnsmasq to deal with dhcpv6 but i never 
tried it. Maybe you can look on this side to reach your goal.


Xavier

Le 10/05/2015 02:42, brian mullan a écrit :

Xavier

I am just learning ipv6 but as I understand it from my reading so far
similar solutions exist in ipv6 as for ipv4 such as dhcp6 etc.

There is stateless address autoconfiguration
(https://tools.ietf.org/html/rfc4862) and Neighbor Discovery protocol (NDP)
for ipv6 (https://tools.ietf.org/html/rfc4861).

NDP seems to only be used on local link for address discovery but that would
seem appropriate for lxc container address assignments !

 From what I understand so far IPv6 has two types of auto-configuration:

Stateless auto-configuration (the RFC mentioned above) which is intended
for small orgs   individual use.  Because this method needs no server to
approve the use of an address its supposed to be simpler to implement.

It's intended to let a host propose an ipv6 address based on the ipv6
network prefix  the host interface MAC address (see EUI-64).  This
assumes the result will be a unique ipv6 address (re no address conflicts).

Stateful auto-configuration uses the dhcp6 protocol.   dhcp6 is called
stateful” because both the dhcp6 server  the client have to keep state
information to insure no address conflicts occur  to manage
lease/lease-renewals.

I was hoping that either someone had used something in these areas to
implement an automatic local ipv6 address assignment to LXC containers
created on any one host or knew of a guide somewhere related to ipv6  lxc.

Thanks for your reply!

Brian


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


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

Re: [lxc-users] Is there a guide to LXC ipv6 configuration

[Xavier Gendre]

Hi,

you can simply pass the IPv6 address you want to give to your container 
via the configuration file through 'lxc.network.ipv6'. For instance, if 
you gave the local address fe80::1 to the interface lxcbr0, you can do 
it with the following configuration file:


# Sample config file
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.ipv6 = [the ipv6 address here]/128
lxc.network.ipv6.gateway = fe80::1

Note that you can give multiple IPv6 addresses by writing multiple lines 
which start with 'lxc.network.ipv6'. This is useful for giving a local 
and a global address to the interface in the container, for instance.


Then, create your container with the following command,
lxc-create -n container_name -f /path/to/config_file -t xxx [...]

Your container will receive the given IPv6 address. The sequel is just 
routing IPv6 traffic (ip -6 route add [...]) and allowing it in your 
firewall (ip6tables [...]).


Do not hesitate to ask if you need more details.

Xavier


Le 09/05/2015 20:32, Miroslav Lednicky a écrit :

Hello,

you can use file /etc/network/interfaces inside LXC for define IPv6
static addrese.

For example:

auto eth0
iface eth0 inet static
 address 1.1.1.2
 netmask 255.255.255.0
 gateway 1.1.1.1
iface eth0 inet6 static
 address 1981:22:33:33::2
 netmask 64
 gateway 1981:22:33:33::1

It is similar as in normal server.

Miroslav Lednický


Dne 9.5.2015 v 18:48 brian mullan napsal(a):

LXC default is to setup NAT'd ipv4 for containers.

is there any guide to how to change the default to setup ipv6 instead so
lxc-create -t  -n cn_name

cn_name ends up with an ipv6 address.

I searched thru all the lxc-users archive and didn't find any mention of
this
and google searches tend to just show examples of static ipv6 config for
a container

I was hoping there was the ipv6 equivalent of the default ipv4
lxc-create results.

brian



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


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

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

Re: [lxc-users] Debian stable not present in the image list of lxc-template-download

[Xavier Gendre]

I don't know but i also can help if there is something to do...

Xavier

Le 03/05/2015 22:40, J Bc a écrit :

Can we help with lxc package in debian?
wiki for compilation and packaging?

2015-05-03 21:39 GMT+02:00 Xavier Gendre gendre.rei...@gmail.com:

The package lxc 1.0.7 has recently changed from experimental to unstable,

https://packages.debian.org/sid/lxc

We can hope that it will be soon available in jessie-backports... After
1.0.7, the next version is 1.1.0. Thus, with a bit of patience, i think that
we will see this version in some repository sooner. It has to be seen with
Daniel Baumann who maintains the package lxc for Debian (maybe he has
subscribed to this list).

About this last point, i deeply thank Daniel Baumann for its work around the
lxc package ;-)

Xavier


Le 03/05/2015 09:59, Johannes Graumann a écrit :



  From http://tinyurl.com/nljucs9


Package lxc

 squeeze (oldoldstable) (admin): Linux containers userspace tools
 0.7.2-1: ...
 squeeze-backports (admin): Linux Containers userspace tools
 0.8.0~rc1-4~bpo60+1 [backports]: ...
 wheezy (oldstable) (admin): Linux Containers userspace tools
 0.8.0~rc1-8+deb7u2: ...
 jessie (stable) (admin): Linux Containers userspace tools
 1:1.0.6-6: ...
 stretch (testing) (admin): Linux Containers userspace tools
 1:1.0.6-6: ...
 sid (unstable) (admin): Linux Containers userspace tools
 1:1.0.7-3: ...
 1:1.0.6-6 [debports]: ...



No 1.1 anywhere.

Joh

Joris Michaux wrote:


Install wheezy and dist upgtade ? :)
Le 3 mai 2015 9:40 AM, Johannes Graumann
johannes_graum...@web.de a écrit :


Stéphane Graber wrote:


On Sat, May 02, 2015 at 01:14:13PM +0200, Jean-François Gigand wrote:


Hi,

I need the current Debian stable (jessie) from the LXC download


template.


How do I get it?

I can help building it.
What is the governance model for maintaining the images on
http://images.linuxcontainers.org/ ?

Thanks,

Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/



Debian Jessie images are available on the image server, but only for
users of LXC 1.1 or higher as jessie uses systemd which isn't supported
in LXC prior to 1.1 (combined with lxcfs).




What's the most sane path to get 1.1 on debian, then?

Sincerely, Joh

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




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


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

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


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

Re: [lxc-users] Debian stable not present in the image list of lxc-template-download

[Xavier Gendre]

The package lxc 1.0.7 has recently changed from experimental to unstable,

https://packages.debian.org/sid/lxc

We can hope that it will be soon available in jessie-backports... After 
1.0.7, the next version is 1.1.0. Thus, with a bit of patience, i think 
that we will see this version in some repository sooner. It has to be 
seen with Daniel Baumann who maintains the package lxc for Debian (maybe 
he has subscribed to this list).


About this last point, i deeply thank Daniel Baumann for its work around 
the lxc package ;-)


Xavier

Le 03/05/2015 09:59, Johannes Graumann a écrit :


 From http://tinyurl.com/nljucs9


Package lxc

squeeze (oldoldstable) (admin): Linux containers userspace tools
0.7.2-1: ...
squeeze-backports (admin): Linux Containers userspace tools
0.8.0~rc1-4~bpo60+1 [backports]: ...
wheezy (oldstable) (admin): Linux Containers userspace tools
0.8.0~rc1-8+deb7u2: ...
jessie (stable) (admin): Linux Containers userspace tools
1:1.0.6-6: ...
stretch (testing) (admin): Linux Containers userspace tools
1:1.0.6-6: ...
sid (unstable) (admin): Linux Containers userspace tools
1:1.0.7-3: ...
1:1.0.6-6 [debports]: ...


No 1.1 anywhere.

Joh

Joris Michaux wrote:


Install wheezy and dist upgtade ? :)
Le 3 mai 2015 9:40 AM, Johannes Graumann
johannes_graum...@web.de a écrit :


Stéphane Graber wrote:


On Sat, May 02, 2015 at 01:14:13PM +0200, Jean-François Gigand wrote:

Hi,

I need the current Debian stable (jessie) from the LXC download

template.

How do I get it?

I can help building it.
What is the governance model for maintaining the images on
http://images.linuxcontainers.org/ ?

Thanks,

Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/


Debian Jessie images are available on the image server, but only for
users of LXC 1.1 or higher as jessie uses systemd which isn't supported
in LXC prior to 1.1 (combined with lxcfs).




What's the most sane path to get 1.1 on debian, then?

Sincerely, Joh

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



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


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

Re: [lxc-users] [Unable to start using lvm backend]

[Xavier Gendre]

It may be useful to give more details about what i am trying to do ;-) I 
work with a Debian Jessie and LXC 1.0.6 from the Debian repository.


First, i give an ID range to root and i set the container's 
configuration with this range:


root # grep root /etc/sub[ug]id
/etc/subgid:root:558752:65536
/etc/subuid:root:558752:65536

root # cat test.conf
lxc.id_map = u 0 558752 65536
lxc.id_map = g 0 558752 65536
lxc.network.type = empty

Then, i create a container with the 'download' template,

root # lxc-create -n test -f test.conf -t download -B lvm --vgname Pool 
-- -d debian -r wheezy -a amd64
File descriptor 3 (/var/lib/lxc/test/partial) leaked on lvcreate 
invocation. Parent PID 1506: lxc-create

  Logical volume test created
Using image from local cache
Unpacking the rootfs
[...]

Finally, i try to start this container but it miserably fails,

root # lxc-start -n test --logfile test.log --logpriority DEBUG
lxc-start: failed to determine fs type for '/dev/Pool/test'
lxc-start: failed to determine fs type for '/dev/dm-7'
lxc-start: failed to mount rootfs
lxc-start: failed to setup rootfs for 'test'
lxc-start: Error setting up rootfs mount after spawn
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'test'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the 
--logfile and --logpriority options.


Here is the content of the log file if it helps,

root # cat test.log
  lxc-start 1428924388.945 INFO lxc_start_ui - using rcfile 
/var/lib/lxc/test/config
  lxc-start 1428924388.945 INFO lxc_confile - read uid map: 
type u nsid 0 hostid 558752 range 65536
  lxc-start 1428924388.945 INFO lxc_confile - read uid map: 
type g nsid 0 hostid 558752 range 65536
  lxc-start 1428924388.945 WARN lxc_log - lxc_log_init called 
with log already initialized

  lxc-start 1428924388.945 INFO lxc_lsm - LSM security driver nop
  lxc-start 1428924388.947 DEBUGlxc_conf - allocated pty 
'/dev/pts/3' (5/6)
  lxc-start 1428924388.947 DEBUGlxc_conf - allocated pty 
'/dev/pts/4' (7/8)
  lxc-start 1428924388.947 DEBUGlxc_conf - allocated pty 
'/dev/pts/5' (9/10)
  lxc-start 1428924388.947 DEBUGlxc_conf - allocated pty 
'/dev/pts/6' (11/12)

  lxc-start 1428924388.947 INFO lxc_conf - tty's configured
  lxc-start 1428924388.947 DEBUGlxc_start - sigchild handler set
  lxc-start 1428924388.947 DEBUGlxc_console - opening /dev/tty 
for console peer
  lxc-start 1428924388.947 DEBUGlxc_console - using '/dev/tty' 
as console
  lxc-start 1428924388.947 DEBUGlxc_console - 1587 got SIGWINCH 
fd 17
  lxc-start 1428924388.947 DEBUGlxc_console - set winsz 
dstfd:14 cols:145 rows:58

  lxc-start 1428924388.947 INFO lxc_start - 'test' is initialized
  lxc-start 1428924388.948 DEBUGlxc_start - Not dropping 
cap_sys_boot or watching utmp
  lxc-start 1428924388.961 DEBUGbdev - trying to mount 
'/dev/Pool/test'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext3'
  lxc-start 1428924388.971 INFO bdev - mounted '/dev/Pool/test' 
on '/usr/lib/x86_64-linux-gnu/lxc/rootfs', with fstype 'ext3'
  lxc-start 1428924388.971 DEBUGlxc_conf - mounted 
'/dev/Pool/test' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
  lxc-start 1428924388.971 INFO lxc_start - Set up container 
rootfs as host root
  lxc-start 1428924388.971 INFO lxc_start - Cloning a new user 
namespace
  lxc-start 1428924388.971 INFO lxc_cgroup - cgroup driver 
cgroupfs initing for test
  lxc-start 1428924388.983 NOTICE   lxc_start - switching to 
gid/uid 0 in new user namespace
  lxc-start 1428924388.984 DEBUGbdev - trying to mount 
'/dev/Pool/test'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext3'
  lxc-start 1428924388.984 DEBUGbdev - mount failed with error: 
Operation not permitted
  lxc-start 1428924388.984 DEBUGbdev - trying to mount 
'/dev/Pool/test'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext2'
  lxc-start 1428924388.984 DEBUGbdev - mount failed with error: 
Operation not permitted
  lxc-start 1428924388.984 DEBUGbdev - trying to mount 
'/dev/Pool/test'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext4'
  lxc-start 1428924388.984 DEBUGbdev - mount failed with error: 
Operation not permitted
  lxc-start 1428924388.984 ERRORbdev - failed to determine fs 
type for '/dev/Pool/test'
  lxc-start 1428924388.985 DEBUGlxc_conf - trying to mount 
'/dev/dm-7'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext3'
  lxc-start 1428924388.985 DEBUGlxc_conf - mount failed with 
error: Operation not permitted
  lxc-start 1428924388.985 DEBUGlxc_conf - trying to mount 
'/dev/dm-7'-'/usr/lib/x86_64-linux-gnu/lxc/rootfs' with fstype 'ext2'
  lxc-start 1428924388.985 DEBUGlxc_conf - mount failed 

Re: [lxc-users] [Unable to start using lvm backend]

[Xavier Gendre]

Hello Fajar,


It may be useful to give more details about what i am trying to do ;-) I
work with a Debian Jessie and LXC 1.0.6 from the Debian repository.


You should realy use at least 1.0.7 from experimental, or better yet, 1.1.1.


That was a good advice... with 1.0.7 from experimental, everything works 
like a charm. I can create root owned unprivileged containers with lvm 
backend and start them without any tweak (no chmod, ...).


Thank you for spending some time on my problem and giving me hope with a 
working example ;-)


Xavier




Finally, i try to start this container but it miserably fails,

root # lxc-start -n test --logfile test.log --logpriority DEBUG
lxc-start: failed to determine fs type for '/dev/Pool/test'
lxc-start: failed to determine fs type for '/dev/dm-7'
lxc-start: failed to mount rootfs



Works for me, just needed a chmod (which is shown on the helpful error
message that I get). This is lxc 1.1.1+master~20150407-0 from ubuntu
daily ppa.

# cat /etc/subuid
lxc-dnsmasq:10:1
user:10:65537
root:100:10

# cat /etc/subgid
lxc-dnsmasq:10:1
user:10:65537
root:100:10

# cat  END  /tmp/test.conf

lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = empty
END


# lxc-create -n test -f /tmp/test.conf -t download -B lvm --vgname lxc
-- -d ubuntu -r utopic -a amd64
File descriptor 3 (/var/lib/lxc/test/partial) leaked on lvcreate
invocation. Parent PID 24304: lxc-create
   Logical volume test created
Using image from local cache
Unpacking the rootfs

---
You just created an Ubuntu container (release=utopic, arch=amd64,
variant=default)

To enable sshd, run: apt-get install openssh-server

For security reason, container images ship without user accounts
and without a root password.

Use lxc-attach or chroot directly into the rootfs to set a root password
or create user accounts.

# lxc-start -n test
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 346 To get more details, run the
container in foreground mode.
lxc-start: lxc_start.c: main: 348 Additional information can be
obtained by setting the --logfile and --logpriority options.

# lxc-start -F -n test
lxc-start: start.c: print_top_failing_dir: 102 Permission denied -
could not access /var/lib/lxc.  Please grant it 'x' access, or add an
ACL for the container root.
lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2
lxc-start: start.c: __lxc_start: 1157 failed to spawn 'test'
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 348 Additional information can be
obtained by setting the --logfile and --logpriority options.

# chmod o+x /var/lib/lxc

# lxc-start -n test

# lxc-ls -f --running
NAME  STATEIPV4  IPV6  GROUPS  AUTOSTART

test  RUNNING  - - -   NO

# lxc-attach -n test -- cat /proc/1/uid_map
  0100 10


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

Re: [lxc-users] [Unable to start using lvm backend]

[Xavier Gendre]

Hi Serge,

please, can you give more details about your settings of root owned 
unprivileged container with LVM backend? Indeed, I encounter the same 
problem as Andrea. I have tried to set the container as you explain but 
it fails to run...


root # grep lxc.id_map /var/lib/lxc/test/config
lxc.id_map = u 0 558752 65536
lxc.id_map = g 0 558752 65536

root # grep root /etc/sub[ug]id
/etc/subgid:root:558752:65536
/etc/subuid:root:558752:65536

root # lxc-start -n test
lxc-start: failed to determine fs type for '/dev/Pool/test'
lxc-start: failed to determine fs type for '/dev/dm-7'
lxc-start: failed to mount rootfs
lxc-start: failed to setup rootfs for 'test'
lxc-start: Error setting up rootfs mount after spawn
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'test'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the 
--logfile and --logpriority options.


I use the download template with a Debian Wheezy 64 for this container.

Thanks,
Xavier

Le 25/01/2015 01:11, Serge Hallyn a écrit :

Yes, unprivileged users cannot manipulate the lvm devices on the host.

You can still use user namespaces though.  I have a few containers on my main
server which do that.  They each run in a unique uid range, but are started by
root, so that they can use lvm (actually luks-encrypted lvm) backends.

Just add the lxc.id_map lines as per usual to containers which are owned by
root.  And make sure to allocate the ranges to root in /etc/sub[ug]id.

-serge

Quoting Andrea Masi (eracli...@gmail.com):

The problem seems related to unprivileged containers that seems cannot work
with -B lvm.
Must we assume that lvm backed store (and maybe others) actually cannot
work with unprivileged containers?


2015-01-23 17:02 GMT+01:00 Andrea Masi eracli...@gmail.com:


Hi,
I'm using lxc 1.0.6 on ubuntu 14.04.
I've no problems creating/running on dir backing store but when I use lvm
I cannot start containers getting these errors:

lxc-start 1422026234.562 ERRORbdev - failed to determine fs type for
'/dev/lxc/lvm-cont'
lxc-start 1422026234.563 ERRORlxc_conf - failed to determine fs type
for '/dev/dm-0'
lxc-start 1422026234.564 ERRORlxc_conf - failed to mount rootfs
lxc-start 1422026234.564 ERRORlxc_conf - failed to setup rootfs for
'lvm-cont'
lxc-start 1422026234.565 ERRORlxc_conf - Error setting up rootfs mount
after spawn
lxc-start 1422026234.565 ERRORlxc_start - failed to setup the container
lxc-start 1422026234.566 ERRORlxc_sync - invalid sequence number 1.
expected 2
lxc-start 1422026234.566 ERRORlxc_start - failed to spawn 'lvm-cont'
lxc-start 1422026234.574 ERRORlxc_start_ui - The container failed to
start.
lxc-start 1422026234.575 ERRORlxc_start_ui - Additional information
can be obtained by setting the --logfile and --logpriority options.

I've tried different template createds with -t download for example:
lxc-create -t download -n lvm-cont -B lvm -- -d ubuntu -r utopic -a amd64

I can manually mount with no problem /dev/lxc/lvm-cont

Any idea on what can it be wrong?

Thanks.

--
www.eraclitux.com





--
www.eraclitux.com



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


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


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

Re: [lxc-users] Owner of an unprivileged container

[Xavier Gendre]

Hi Serge,

Le 03/04/2015 23:46, Serge Hallyn a écrit :

Quoting Xavier Gendre (gendre.rei...@gmail.com):

Hello,

I run several containers on my server and, following the security
advices, they are unprivileged. Each container belongs to one user
and I am asking myself if this is a good practice...

Thus my question is if there are some differences between:
- an unprivileged container owned by root with 'lxc.id_map' in its
config file to make it unprivileged,
- a similar unprivileged container but owned by a classical user.

 From the practical point of view, I have to admit that a container
owned by root is easier to handle but, from the security point of
view, is it more safe to give the unprivileged container to an user
than to root? Or is the namespace sufficient to avoid escape from an
unprivileged container that belongs to root?


The main difference would be that the container startup and the
container monitor end up running as root if started by root.  This
is a pretty small, but not zero, attack surface.


Thank you for these security informations. Indeed, this is not a zero 
attack surface but i have to admit that this is a sufficiently small one 
for my little server.



What are your good practices in the matter? All belong to root?
All belong to one devoted user? Or, as what I do, one user for one
container?


Currently that's probably mainly decided by practicality.  If you
want to use an encrypted lvm backing store (I do) then you need
to have root start the container.  The biggest advantage in my
opinion of using fully unprivileged containers (starting them as
non-root user) is so that users other than you can create/start
them without having root access.  Failing that, I still prefer to
use fully unpriv containers myself when possible, to reduce the
amount of time I spend as root.


I have discussed about that with some people in the irc chan 
#lxcontainers and i agree with you. Unprivileged root-owned containers 
are quite unavoidable for some particular usage. In the future, i will 
keep the simple containers as user-owned and put the complicated ones as 
root-owned. Anyway, i will deal with some trade-off between root and 
user ownership ;-)


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

[lxc-users] Owner of an unprivileged container

[Xavier Gendre]

Hello,

I run several containers on my server and, following the security 
advices, they are unprivileged. Each container belongs to one user and I 
am asking myself if this is a good practice...


Thus my question is if there are some differences between:
- an unprivileged container owned by root with 'lxc.id_map' in its 
config file to make it unprivileged,

- a similar unprivileged container but owned by a classical user.

From the practical point of view, I have to admit that a container 
owned by root is easier to handle but, from the security point of view, 
is it more safe to give the unprivileged container to an user than to 
root? Or is the namespace sufficient to avoid escape from an 
unprivileged container that belongs to root?


What are your good practices in the matter? All belong to root? All 
belong to one devoted user? Or, as what I do, one user for one container?


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

Re: [lxc-users] Advice for running LXC on a Debian host

[Xavier Gendre]

Hi,

I am not as categorical as Fajar and using LXC with Debian is widely 
feasable. I admit that the LXC version that comes with Debian Stable is 
not enough up to date. But I have installed Debian Jessie and I use the 
Debian's package that give LXC with version 1.0.6.


Of course, if you need all the last functionalities easily available, 
you will have to follow the advices of Fajar and dealing with Ubuntu is 
certainly easier. If you don't need that, Debian Jessie and LXC work 
(quite) like a charm and it suits all my needs.


Xavier

Le 14/03/2015 06:55, Fajar A. Nugraha a écrit :

On Fri, Mar 13, 2015 at 8:34 PM, Rory Campbell-Lange
r...@campbell-lange.net wrote:

Dear LXC List

I'm looking for advice on running LXC on Debian.

I did quite a lot of work on trialling lxc about two years ago but then
left it there because of a lack of time and some troublesome issues with
Debian stable at the time.


Short suggestion: don't.

It's MUCH easier to use ubuntu LTS + lxc (either from bundled version,
or from daily ppa to get latest lxc version) as the host. You'd likely
get problems with debian's bundled version, as reported on this list
recently (search the archives). And building your own lxc version (or
rebuilding ubuntu's source) might not be as straightforward as it
seems.

You could then run whatever you want on the containers, including debian.



We are considering using LXC again for a spare server to take over a
couple of small production server images where the hardware is reaching
end-of-life. Also we wish to be able to quickly setup clones/variants of
our web application stack (postgresql + php/python + apache) for testing
purposes.

The machine we have available has 6GB of RAM, a system (hw raid 1) 200G
drive and a storage drive (hw raid 5) of 1TB. The board is a TYAN
Tempest with 8 x Intel E5420 @ 2.50GHz. We have been trialling btrfs for
some years now and are happy to take the risks of running the storage
drive on btrfs.



I'd suggest zfs, but if you're comfortable with btrfs, then lxc has
support for it as well (e.g. container snapshot/clone)



Presently the Debian LXC wiki page at https://wiki.debian.org/LXC states
LXC may not provide sufficient isolation at this time.


Part of the lxc isolation/security in ubuntu is provided thru
apparmor, which AFAIK is not enabled by default on debian.

The other part is thru the use of unprivileged containers (where
container's root uid is just another non-root uid in the host).



I would be grateful for comments about whether a version of Debian is
suitable for these intended uses, what Debian distro version is
recommended (if any), what kernel version to run and recommendations
about using btrfs.



I'd go with ubuntu 14.04, lxc-1.1 from daily ppa, and add zfsonlinux.

If you still want to use debian anyway, then probably debian stable
plus lxc-1.1 built manually from source.
Use whatever kernel version that you've tested to work well with for
btrfs (I lost track of which versions, but there were some newer
kernels which caused btrfs regression).
Then, if you care about security, find out how you can enable apparmor
and integrate it with your lxc buid.


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

Re: [lxc-users] User namespaces

[Xavier Gendre]

Hi,

a priori, no problem with doing that. Simply deal with /etc/subuid and 
/etc/subgid (on debian-like system, at least). For the limit, I don't 
know but the man page for newuidmap considers integers. Thus, we could 
hope to deal with 2^32=4294967296 ids. In such a case, you have some 
room to manoeuvre ;-)


Xavier

Le 28/02/2015 12:24, david.an...@bli.uzh.ch a écrit :

Hi,

I am looking into individual user namespaces for each container.
The first container could have uids and gids from 10 to 165536.
The second container could have 20 to 265536, couldn't it?
How far can I go? Is there a limit?

Thanks,
David


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


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

[lxc-users] Unprivileged containers on Debian Jessie

[Xavier Gendre]

Hi,

following the hints given by Serge Hallyn on the lxc-devel list, I 
managed to run an unprivileged container on my Debian Jessie \o/


Now, I want to avoid handlings and get it works on startup. Thus, I set 
permanently kernel.unprivileged_userns_clone to 1 and I create a systemd 
service to run the following script:


#!/bin/bash

echo 1  /sys/fs/cgroup/cpuset/cgroup.clone_children

# Allowed users
lxc_users=user1 user2

for u in $lxc_users; do
  for d in /sys/fs/cgroup/*; do
mkdir -p $d/$u
chown -R $u: $d/$u
  done
done

The only thing that I need now is to put a 'good' PID in the tasks files 
in order to be allowed to start my unprivileged containers. I can do 
that by login as an allowed user and by putting the PID of the current 
shell in my tasks file. But this solution is volatile and has to be done 
on each startup for each container :-/


Is my approach good? Maybe there is a simpler solution to my problem... 
If this is the way, how can I put a valid PID in the tasks files of the 
allowed users on startup in order, for example, to autostart some 
unprivileged containers?


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