Przemyslaw Rudy | 28 Jul 16:10 2015
Picon

ramfs userns /proc umount2

Referring to this patch:
https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-October/010604.html

Starting lxc with userns in prepare_ramfs_root() I got -1 from:
if (umount2("./proc", MNT_DETACH)) {

Shall this error be rather ignored in case of userns? Thus the same
logic as for other mount points processed by mentioned function?
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Divya Vyas | 28 Jul 11:20 2015
Picon

Fwd: cgroup error in lxc-start

Hi,

I am using lxc-1.0.7  and while lxc-start I am getting this error

lxc/start.c: __lxc_start: 1080 failed to spawn 'vm0
lxc/cgfs.c: cgroup_rmdir: 207 Device or resource busy - cgroup_rmdir: failed to delete /cgroup/lxc/vm0

My mount output is :

/dev/sda10 on / type ext4 (rw,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=4016144k,nr_inodes=1004036,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/volatile type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
cgroup on /cgroup type cgroup (rw,relatime,cpuset,cpu,cpuacct,memory,devices,freezer,net_cls,blkio,perf_event,net_prio,hugetlb,debug,clone_children)

Please give me some advice where I could be wrong?



_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Wolfgang Bumiller | 27 Jul 10:24 2015

seccomp, lxcfs and force-unmount

(I only recently subscribed to the list so forgive me if there's already
a thread I should be replying to instead of opening a new one.)

So I came across the force-unmount issue where `umount -f` on any of the
bind mounts can cause lxcfs on the host to terminate.

I find the seccomp solution to be rather crude as force-unmount might
have some legitimate usecases inside a container, and the seccomp way
cannot be limited to certain paths. And it's still problematic with 32
bit containers on 64 bit hosts, as mentioned in #571 due to
reject_force_umount being incorrectly resolved to systemcalls (and
getting equal -1 IDs from it).
I'd like to know why this is even necessary, as I don't see a reason to
care about IDs since as far as I can tell you _do_ need to add them to
both contexts.  (Which is what I do in my pull request #600 - awaiting
review/comments).

Here's the idea/suggestion:
I'm wondering if it would instead make sense to spawn an lxcfs process
per container. If this is problematic due to lxcfs' design the only
other way I see to support force-unmount inside containers would be to
spawn a bindfs (fuse bind) per container between the container and
lxcfs, in which case the force-unmount would only terminate the bind,
rather than the lxcfs itself.

Either way I'd be willing to work on some patches if I know which
direction to go.

_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Wolfgang Bumiller | 27 Jul 07:33 2015

[PATCH v2] pass on reboot flag and delete old veth on reboot

When setting lxc.network.veth.pair to get a fixed interface
name the recreation of it after a reboot caused an EEXIST.
-) The reboot flag is now a three-state value. It's set to
1 to request a reboot, and 2 during a reboot until after
lxc_spawn where it is reset to 0.
-) If the reboot is set (!= 0) within instantiate_veth and
a fixed name is used, the interface is now deleted before
being recreated.

Signed-off-by: Wolfgang Bumiller <w.bumiller <at> proxmox.com>
---
 src/lxc/conf.c         | 6 ++++--
 src/lxc/lxccontainer.c | 6 +++---
 src/lxc/start.c        | 2 ++
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 9870455..ed2ad66 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
 <at>  <at>  -2613,9 +2613,11  <at>  <at>  static int instantiate_veth(struct lxc_handler *handler, struct lxc_netdev *netd
 	char veth2buf[IFNAMSIZ], *veth2;
 	int err;

-	if (netdev->priv.veth_attr.pair)
+	if (netdev->priv.veth_attr.pair) {
 		veth1 = netdev->priv.veth_attr.pair;
-	else {
+		if (handler->conf->reboot)
+			lxc_netdev_delete_by_name(veth1);
+	} else {
 		err = snprintf(veth1buf, sizeof(veth1buf), "vethXXXXXX");
 		if (err >= sizeof(veth1buf)) { /* can't *really* happen, but... */
 			ERROR("veth1 name too long");
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 1c103e8..223e78e 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
 <at>  <at>  -760,9 +760,9  <at>  <at>  static bool do_lxcapi_start(struct lxc_container *c, int useinit, char * const a
 		pid_fp = NULL;
 	}

-reboot:
 	conf->reboot = 0;

+reboot:
 	if (lxc_check_inherited(conf, daemonize, -1)) {
 		ERROR("Inherited fds found");
 		ret = 1;
 <at>  <at>  -772,9 +772,9  <at>  <at>  reboot:
 	ret = lxc_start(c->name, argv, conf, c->config_path, daemonize);
 	c->error_num = ret;

-	if (conf->reboot) {
+	if (conf->reboot == 1) {
 		INFO("container requested reboot");
-		conf->reboot = 0;
+		conf->reboot = 2;
 		goto reboot;
 	}

diff --git a/src/lxc/start.c b/src/lxc/start.c
index 6eded61..2fc026e 100644
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
 <at>  <at>  -1173,6 +1173,8  <at>  <at>  int __lxc_start(const char *name, struct lxc_conf *conf,
 		goto out_detach_blockdev;
 	}

+	handler->conf->reboot = 0;
+
 	netnsfd = get_netns_fd(handler->pid);

 	err = lxc_poll(name, handler);
--

-- 
2.1.4

_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Wolfgang Bumiller | 24 Jul 09:00 2015

[PATCH] make reboot with persistent veth name work

In this patch I'm simply deleting the old network interface before
recreating it when a persistent interface name was used. I think this
makes sense since mac addresses are reconfigured, and the peer would
otherwise already sit in the other namespace making this otherwise a
more difficult task AFAIK.

In order to know when to do this I moved the palce where conf->reboot
is reset toa fter lxc_spawn. A quick grep through the source showed
that this should be fine, though if another solution is desired I'm
willing to work on this a bit more.

On an unrelated note: I've noticed that sometimes pull requests from github
don't seem to make it to the devel list. With my first PR I thought it
was due to the missing email address association on github (and I saw
it appear on the list after fixing this and commenting about it within
the PR), but my current one about seccomp didn't show up in my mailbox
either. Is this intended?

Wolfgang Bumiller (1):
  pass on reboot flag and delete old veth on reboot

 src/lxc/conf.c         | 6 ++++--
 src/lxc/lxccontainer.c | 3 +--
 src/lxc/start.c        | 2 ++
 3 files changed, 7 insertions(+), 4 deletions(-)

--

-- 
2.1.4

_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
GitHub | 22 Jul 17:56 2015

[lxc/lxc] f5fd66: Fix Android build due to missing constant

  Branch: refs/heads/master
  Home:   https://github.com/lxc/lxc
  Commit: f5fd66f70ab513a1175f42ea8a878fc985725ce4
      https://github.com/lxc/lxc/commit/f5fd66f70ab513a1175f42ea8a878fc985725ce4
  Author: Stéphane Graber <stgraber@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/bdev.c

  Log Message:
  -----------
  Fix Android build due to missing constant

Signed-off-by: Stéphane Graber <stgraber@...>

_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
GitHub | 22 Jul 16:13 2015

[lxc/lxc] 405634: lxc-net.conf: use +e at teardown

  Branch: refs/heads/stable-1.0
  Home:   https://github.com/lxc/lxc
  Commit: 4056340ae7ac5b3a6b31a47c5324df7328dccba0
      https://github.com/lxc/lxc/commit/4056340ae7ac5b3a6b31a47c5324df7328dccba0
  Author: Serge Hallyn <serge.hallyn@...>
  Date:   2015-04-06 (Mon, 06 Apr 2015)

  Changed paths:
    M config/init/upstart/lxc-net.conf

  Log Message:
  -----------
  lxc-net.conf: use +e at teardown

When we are shutting down the lxc network, we should not fail when
things go wrong, as that only makes it harder to clean up later.

See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1429140 in particular

Signed-off-by: Serge Hallyn <serge.hallyn@...>
Acked-by: Stéphane Graber <stgraber@...>

  Commit: f547349ea7ef3a6eae6965a95cb5986cd921bd99
      https://github.com/lxc/lxc/commit/f547349ea7ef3a6eae6965a95cb5986cd921bd99
  Author: Serge Hallyn <serge.hallyn@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/lxclock.c
    M src/tests/locktests.c

  Log Message:
  -----------
  CVE-2015-1331: lxclock: use /run/lxc/lock rather than /run/lock/lxc

This prevents an unprivileged user to use LXC to create arbitrary file
on the filesystem.

Signed-off-by: Serge Hallyn <serge.hallyn@...>
Signed-off-by: Tyler Hicks <tyhicks@...>
Acked-by: Stéphane Graber <stgraber@...>

  Commit: 15ec0fd9d490dd5c8a153401360233c6ee947c24
      https://github.com/lxc/lxc/commit/15ec0fd9d490dd5c8a153401360233c6ee947c24
  Author: Stéphane Graber <stgraber@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/attach.c

  Log Message:
  -----------
  CVE-2015-1334: Don't use the container's /proc during attach

A user could otherwise over-mount /proc and prevent the apparmor profile
or selinux label from being written which combined with a modified
/bin/sh or other commonly used binary would lead to unconfined code
execution.

Reported-by: Roman Fiedler
Signed-off-by: Stéphane Graber <stgraber@...>

Compare: https://github.com/lxc/lxc/compare/dbbfd438e7c4...15ec0fd9d490
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
GitHub | 22 Jul 16:11 2015

[lxc/lxc] 61ecf6: CVE-2015-1331: lxclock: use /run/lxc/lock rather t...

  Branch: refs/heads/stable-1.1
  Home:   https://github.com/lxc/lxc
  Commit: 61ecf69d7834921cc078e14d1b36c459ad8f91c7
      https://github.com/lxc/lxc/commit/61ecf69d7834921cc078e14d1b36c459ad8f91c7
  Author: Serge Hallyn <serge.hallyn@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/lxclock.c
    M src/tests/locktests.c

  Log Message:
  -----------
  CVE-2015-1331: lxclock: use /run/lxc/lock rather than /run/lock/lxc

This prevents an unprivileged user to use LXC to create arbitrary file
on the filesystem.

Signed-off-by: Serge Hallyn <serge.hallyn@...>
Signed-off-by: Tyler Hicks <tyhicks@...>
Acked-by: Stéphane Graber <stgraber@...>

  Commit: 659e807c8dd1525a5c94bdecc47599079fad8407
      https://github.com/lxc/lxc/commit/659e807c8dd1525a5c94bdecc47599079fad8407
  Author: Stéphane Graber <stgraber@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/attach.c

  Log Message:
  -----------
  CVE-2015-1334: Don't use the container's /proc during attach

A user could otherwise over-mount /proc and prevent the apparmor profile
or selinux label from being written which combined with a modified
/bin/sh or other commonly used binary would lead to unconfined code
execution.

Reported-by: Roman Fiedler
Signed-off-by: Stéphane Graber <stgraber@...>

Compare: https://github.com/lxc/lxc/compare/3d6347a4cd69...659e807c8dd1
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
GitHub | 22 Jul 16:10 2015

[lxc/lxc] 72cf81: CVE-2015-1331: lxclock: use /run/lxc/lock rather t...

  Branch: refs/heads/master
  Home:   https://github.com/lxc/lxc
  Commit: 72cf81f6a3404e35028567db2c99a90406e9c6e6
      https://github.com/lxc/lxc/commit/72cf81f6a3404e35028567db2c99a90406e9c6e6
  Author: Serge Hallyn <serge.hallyn@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/lxclock.c
    M src/tests/locktests.c

  Log Message:
  -----------
  CVE-2015-1331: lxclock: use /run/lxc/lock rather than /run/lock/lxc

This prevents an unprivileged user to use LXC to create arbitrary file
on the filesystem.

Signed-off-by: Serge Hallyn <serge.hallyn@...>
Signed-off-by: Tyler Hicks <tyhicks@...>
Acked-by: Stéphane Graber <stgraber@...>

  Commit: 5c3fcae78b63ac9dd56e36075903921bd9461f9e
      https://github.com/lxc/lxc/commit/5c3fcae78b63ac9dd56e36075903921bd9461f9e
  Author: Stéphane Graber <stgraber@...>
  Date:   2015-07-22 (Wed, 22 Jul 2015)

  Changed paths:
    M src/lxc/attach.c

  Log Message:
  -----------
  CVE-2015-1334: Don't use the container's /proc during attach

A user could otherwise over-mount /proc and prevent the apparmor profile
or selinux label from being written which combined with a modified
/bin/sh or other commonly used binary would lead to unconfined code
execution.

Reported-by: Roman Fiedler
Signed-off-by: Stéphane Graber <stgraber@...>

Compare: https://github.com/lxc/lxc/compare/f52c0d2677e3...5c3fcae78b63
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
GitHub | 21 Jul 16:43 2015

[lxc/lxc] 5d066f: lxc-ubuntu-cloud: support passing vendor-data

  Branch: refs/heads/master
  Home:   https://github.com/lxc/lxc
  Commit: 5d066f24e65ef482cdfee241ce65e060d1652efc
      https://github.com/lxc/lxc/commit/5d066f24e65ef482cdfee241ce65e060d1652efc
  Author: Scott Moser <smoser@...>
  Date:   2015-07-21 (Tue, 21 Jul 2015)

  Changed paths:
    M hooks/ubuntu-cloud-prep
    M templates/lxc-ubuntu-cloud.in

  Log Message:
  -----------
  lxc-ubuntu-cloud: support passing vendor-data

vendor-data is supported in Ubuntu cloud images in trusty and later.
This allows the user to pass it in on create or clone.

Signed-off-by: Scott Moser <smoser@...>

  Commit: f52c0d2677e365289e921cfd38033c0c987cefd5
      https://github.com/lxc/lxc/commit/f52c0d2677e365289e921cfd38033c0c987cefd5
  Author: Stéphane Graber <stgraber@...>
  Date:   2015-07-21 (Tue, 21 Jul 2015)

  Changed paths:
    M hooks/ubuntu-cloud-prep
    M templates/lxc-ubuntu-cloud.in

  Log Message:
  -----------
  Merge pull request #597 from smoser/ubuntu-cloud-vendordata

lxc-ubuntu-cloud: support passing vendor-data

Compare: https://github.com/lxc/lxc/compare/b9efb0c91c4e...f52c0d2677e3
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Harald Dunkel | 21 Jul 16:10 2015
Picon

symbolic link for /var/lib/lxc

Hi folks,

please consider this:

# ls -al /var/lib/lxc
lrwxrwxrwx 1 root root 11 Aug 11  2014 /var/lib/lxc -> /export/lxc

# lxc-ls --fancy
NAME          STATE    IPV4           IPV6  GROUPS  AUTOSTART
-------------------------------------------------------------
lxchost01     RUNNING  10.123.96.134  -     auto    BY-GROUP
lxchost02     RUNNING  10.123.99.37   -     auto    BY-GROUP
lxchost03     RUNNING  10.123.96.51   -     auto    BY-GROUP
lxchost04     STOPPED  -              -     auto    NO
lxchost05     RUNNING  10.123.96.46   -     auto    BY-GROUP
lxchost06     RUNNING  10.123.96.55   -     auto    BY-GROUP
lxchost07     RUNNING  10.123.99.219  -     auto    BY-GROUP
lxchost08     RUNNING  10.123.96.53   -     auto    BY-GROUP
lxchost09     RUNNING  10.123.96.76   -     auto    BY-GROUP
lxchost10     RUNNING  10.123.99.216  -     auto    BY-GROUP
lxchost11     RUNNING  10.123.99.125  -     auto    BY-GROUP
lxchost12     STOPPED  -              -     -       NO

# lxc-ls -P /export/lxc --fancy
NAME          STATE    IPV4  IPV6  GROUPS  AUTOSTART
----------------------------------------------------
lxchost01     STOPPED  -     -     auto    BY-GROUP
lxchost02     STOPPED  -     -     auto    BY-GROUP
lxchost03     STOPPED  -     -     auto    BY-GROUP
lxchost04     STOPPED  -     -     auto    NO
lxchost05     STOPPED  -     -     auto    BY-GROUP
lxchost06     STOPPED  -     -     auto    BY-GROUP
lxchost07     STOPPED  -     -     auto    BY-GROUP
lxchost08     STOPPED  -     -     auto    BY-GROUP
lxchost09     STOPPED  -     -     auto    BY-GROUP
lxchost10     STOPPED  -     -     auto    BY-GROUP
lxchost11     STOPPED  -     -     auto    BY-GROUP
lxchost12     STOPPED  -     -     -       NO

This looks pretty fragile to me. Shouldn't lxc report the same
state for both paths, no matter what?

Regards
Harri
_______________________________________________
lxc-devel mailing list
lxc-devel <at> lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Gmane