Bug#978425: autopkgtest reboot functionality is broken with cgroupv2

2020-12-27 Thread Christian Brauner 
On Sun, Dec 27, 2020 at 05:28:18PM +0100, Michael Biebl wrote:
> Am 27.12.20 um 16:43 schrieb Christian Brauner:
> > I'll give this a closer look. Is there any way I can tell autopkgtest to

Ok, I think I fixed it:
https://github.com/lxc/lxc/pull/3608
Can you please apply
https://github.com/lxc/lxc/commit/31b84c7a026fb9f75e4f9fc625790af2b6a6c92b.patch
and confirm that it fixes it for you too?

Thanks!
Christian

Bug#978425: autopkgtest reboot functionality is broken with cgroupv2

2020-12-27 Thread Christian Brauner 
On Sun, Dec 27, 2020 at 12:44:16PM +0100, Michael Biebl wrote:
> Thanks for your quick reply, Christian.
> 
> Am 27.12.20 um 12:31 schrieb Christian Brauner:
> > Hm, I have two small fixes in
> > https://github.com/lxc/lxc/pull/3608
> > prefixed with "cgroup2: " in this branch that might fix it in case you
> > can easily test.
> 
> I rebuild the Debian 4.0.5-1 package with those two patches applied, but
> that didn't help unfortunately.
> 
> A debug log is attached.

I'll give this a closer look. Is there any way I can tell autopkgtest to
create trace logs for the lxc containers it runs?

Christian

Bug#978425: autopkgtest reboot functionality is broken with cgroupv2

2020-12-27 Thread Christian Brauner 
On Sun, Dec 27, 2020 at 12:23:47PM +0100, Michael Biebl wrote:
> Am 27.12.20 um 12:05 schrieb Christian Brauner:
> > > $ sudo autopkgtest-build-lxc
> 
> Sorry for the wrong instructions. This should have been:
> $ sudo autopkgtest-build-lxc debian sid

No problem at all; figured it out myself. :)

Hm, I have two small fixes in
https://github.com/lxc/lxc/pull/3608
prefixed with "cgroup2: " in this branch that might fix it in case you
can easily test.

Christian

Bug#978425: autopkgtest reboot functionality is broken with cgroupv2

2020-12-27 Thread Christian Brauner 
On Sun, Dec 27, 2020 at 11:17:18AM +0100, Michael Biebl wrote:
> Package: lxc
> Version: 1:4.0.5-1
> Severity: important
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: cgroupv2
> X-Debbugs-Cc: Christian Brauner 
> 
> 
> Hi,
> 
> since systemd 247.2-2, we default to the unified (i.e. cgroupv2 only)
> cgroup hierarchy in Debian.
> 
> This switch broke the boot-smoke and boot-and-services autopkgtest in
> systemd.
> 
> If you want to reproduce the issue, run the following commands on a
> Debian sid system:
> 
> $ sudo autopkgtest-build-lxc
> $ autopkgtest -o logs-lxc --test-name=boot-smoke systemd -- lxc -s 
> autopkgtest-sid
> 
> This results in:
> 
> autopkgtest [11:04:42]: test boot-smoke: [---
> reboot #0
> bash: line 1:  5918 Killed  
> /tmp/autopkgtest-lxc.8f5ls0o4/downtmp/build.7vt/src/debian/tests/boot-smoke 
> 2> >(tee -a /tmp/autopkgtest-lxc.8f5ls0o4/downtmp/boot-smoke-stderr >&2) > 
> >(tee -a /tmp/autopkgtest-lxc.8f5ls0o4/downtmp/boot-smoke-stdout)
> autopkgtest [11:04:42]: test process requested reboot with marker 1
> lxc-attach: autopkgtest-lxc-pweqwc: attach.c: lxc_attach: 981 Failed to get 
> init pid
> ...
> lxc-attach: autopkgtest-lxc-pweqwc: attach.c: lxc_attach: 981 Failed to get 
> init pid
> : failure: ['sudo', 'timeout', '600', 'lxc-stop', '--quiet', 
> '--kill', '--name', 'autopkgtest-lxc-pweqwc'] failed (exit status 2, stderr 
> '')
> while cleaning up because of another error:
> : failure: timed out waiting for container 
> autopkgtest-lxc-pweqwc to start; last runlevel ""
> autopkgtest [11:06:49]: ERROR: testbed failure: cannot send to testbed: 
> [Errno 32] Broken pipe
> 
> A full build log is attached.
> 
> 
> Since I remember that this worked in the past, I ran git bisect on lxc
> and found the first faulty commit to be
> 
> https://github.com/lxc/lxc/commit/6001872d082dffce5e328049788c7f1ae0864789
> 
> From: Christian Brauner 
> Date: Sun, 3 May 2020 12:01:44 +0200
> Subject: [PATCH] common.conf: add cgroup2 default device limits
> 
> 
> Reverting that patch fixes the systemd autopkgtest suite.
> 
> I'm filing this with severity important, but this should really be fixed
> for bullseye, so should probably be RC.

I'm trying to reproduce this. Let's see how far I get.

Christian

Bug#916639: LXC AppArmor confinement breaks systemd v240

2019-01-13 Thread Christian Brauner 
Did you backport the new config keys as well?
If so we can't carry that version upstream.
Since this would be a feature release.
If you only backported the internal profile changes than we can carry it 
upstream and you should send your patch.

Christian

On January 13, 2019 12:19:43 PM GMT+02:00, intrigeri  
wrote:
>Hi,
>
>Pierre-Elliott Bécue:
>> Hi,
>
>> Le 11/01/2019 à 16:02, Christian Brauner a écrit :
>>> Hm, unlikely. Can you carry a separate patch on top of 3.0.3 until
>>> we release 3.0.4?
>
>> Sure, if it is applicable on top of 3.0.3 I can do it. :)
>
>Note that I've already backported these patches and proposed them here,
>see my initial message on this bug report :)
>
>Cheers,
>-- 
>intrigeri

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#916639: LXC AppArmor confinement breaks systemd v240

2019-01-11 Thread Christian Brauner 
On Fri, Jan 11, 2019 at 03:56:02PM +0100, Pierre-Elliott Bécue wrote:
> Le 11/01/2019 à 15:01, Christian Brauner a écrit :
> > On Fri, Jan 11, 2019 at 12:58:09AM +0100, Pierre-Elliott Bécue wrote:
> >> Le dimanche 16 décembre 2018 à 20:22:05+0100, intrig...@debian.org a écrit 
> >> :
> >>> Package: lxc
> >>> Version: 1:3.0.3-1
> >>> Severity: normal
> >>> Tags: patch
> >>> X-Debbugs-Cc: Michael Biebl , Wolfgang Bumiller 
> >>> 
> >>> User: pkg-apparmor-t...@lists.alioth.debian.org
> >>> Usertags: buggy-profile
> >>>
> >>> Hi,
> >>>
> >>> as discussed on https://bugs.debian.org/911806 the current LXC
> >>> AppArmor support breaks systemd v240, which now refuses to start units
> >>> if it can't set up various sandboxing features, while previously it
> >>> would merely start the units without the configured sandboxing.
> >>> Michael Biebl originally reported this failure in the context of the
> >>> systemd autopkgtests but I expect the same problem will affect regular
> >>> full-system containers as well.
> >>>
> >>> Testing confirms that this problem is fixed by backporting 3 commits
> >>> (e6ec0a9, e7311a84 and 1800f92) from LXC 3.1.0. I'm attaching the
> >>> resulting backported patches. Credit goes to Wolfgang Bumiller who did
> >>> the work upstream and to Michael Biebl who reported the problem in
> >>> great details.
> >>>
> >>> If Buster is going to be released with LXC 3.0.x, IMO we need to
> >>> either apply these patches or disable AppArmor by default for new LXC
> >>> containers. And if we're going to ship with LXC 3.1.0 or newer, then
> >>> feel free to disregard this request and close this bug with the first
> >>> upload of LXC 3.1.0+ :)
> >>
> >> Hi,
> >>
> >> Cc-ing Christian to improve the delay of replies.
> >>
> >> At first I released 3.1.0 in unstable, but it seems unwise to rely on this
> >> one when 3.0 is the LTS and 3.1 support won't last for long.
> >>
> >> Hence I did a 3.1.0+really3.0.3 release today, rollbacking to 3.0.3.
> >>
> >> This means this bug is no longer fixed.
> >>
> >> Christian, would you consider releasing a 3.0.4 containing the patchset
> >> mentioned in this bug?
> > 
> > The three commits you linked would be a feature backport which we can't
> > do into a stable branch. Wolfgang could however send a custom patch. I
> > Cced him. If he does it we can push this into the next release. :)
> 
> Do you mean a 3.0.x release?
> 
> Would it be possible to have it before the end of the month? Otherwise

Hm, unlikely. Can you carry a separate patch on top of 3.0.3 until we
release 3.0.4?

Thanks!
Christian

Bug#916639: LXC AppArmor confinement breaks systemd v240

2019-01-11 Thread Christian Brauner 
On Fri, Jan 11, 2019 at 12:58:09AM +0100, Pierre-Elliott Bécue wrote:
> Le dimanche 16 décembre 2018 à 20:22:05+0100, intrig...@debian.org a écrit :
> > Package: lxc
> > Version: 1:3.0.3-1
> > Severity: normal
> > Tags: patch
> > X-Debbugs-Cc: Michael Biebl , Wolfgang Bumiller 
> > 
> > User: pkg-apparmor-t...@lists.alioth.debian.org
> > Usertags: buggy-profile
> > 
> > Hi,
> > 
> > as discussed on https://bugs.debian.org/911806 the current LXC
> > AppArmor support breaks systemd v240, which now refuses to start units
> > if it can't set up various sandboxing features, while previously it
> > would merely start the units without the configured sandboxing.
> > Michael Biebl originally reported this failure in the context of the
> > systemd autopkgtests but I expect the same problem will affect regular
> > full-system containers as well.
> > 
> > Testing confirms that this problem is fixed by backporting 3 commits
> > (e6ec0a9, e7311a84 and 1800f92) from LXC 3.1.0. I'm attaching the
> > resulting backported patches. Credit goes to Wolfgang Bumiller who did
> > the work upstream and to Michael Biebl who reported the problem in
> > great details.
> > 
> > If Buster is going to be released with LXC 3.0.x, IMO we need to
> > either apply these patches or disable AppArmor by default for new LXC
> > containers. And if we're going to ship with LXC 3.1.0 or newer, then
> > feel free to disregard this request and close this bug with the first
> > upload of LXC 3.1.0+ :)
> 
> Hi,
> 
> Cc-ing Christian to improve the delay of replies.
> 
> At first I released 3.1.0 in unstable, but it seems unwise to rely on this
> one when 3.0 is the LTS and 3.1 support won't last for long.
> 
> Hence I did a 3.1.0+really3.0.3 release today, rollbacking to 3.0.3.
> 
> This means this bug is no longer fixed.
> 
> Christian, would you consider releasing a 3.0.4 containing the patchset
> mentioned in this bug?

The three commits you linked would be a feature backport which we can't
do into a stable branch. Wolfgang could however send a custom patch. I
Cced him. If he does it we can push this into the next release. :)

Thanks!
Christian

Bug#908223: Bug#908192

2018-10-23 Thread Christian Brauner 
On Tue, Oct 23, 2018 at 11:54:08AM +0200, Pierre-Elliott Bécue wrote:
> Le lundi 22 octobre 2018 à 16:39:12+0200, Christian Brauner a écrit :
> > On Mon, Oct 22, 2018 at 02:29:19PM +0200, Pierre-Elliott Bécue wrote:
> > > Cc-ing Christian as he proposed the patch.
> > > 
> > > Le jeudi 18 octobre 2018 à 14:32:12+0200, Matthias Heinz a écrit :
> > > > Hi,
> > > > 
> > > > I've tried applying the patch to the 2.0.9 source. Unfortunately there 
> > > > have 
> > > > been more changes to conf.c since the release of lxc 2.0.9 and this 
> > > > patch wont 
> > > > apply without applying these changes as well.
> > > 
> > > What amount of patches would it represent? Would it be relevant to 
> > > consider
> > > updating lxc in buster to a newer release?
> > 
> > You should definitely consider upgrading to 3.0.0 it will be a huge
> > improvement in so many ways.
> > But I understand that it is work although this might help you :)
> > 
> > https://lists.linuxcontainers.org/pipermail/lxc-devel/2018-April/017663.html
> 
> Let's give it a try.
> 
> First question : where should one install pam_cgfs.so?
> 
> It has no SOVERSION attached to it, and seems to go in /usr/lib/${ARCH}/ by
> default. Would it be better to place it in /usr/lib/security? Do you (as an
> upstream) have a recommendation?
> 
> Same goes for LXC maintainers, where should I put this library?

So on Ubuntu this is put into 

brauner@wittgenstein|~
> ls -al /lib/x86_64-linux-gnu/security/ | grep pam_cgfs
-rw-r--r-- 1 root root  71896 Oct 20 02:19 pam_cgfs.so

so I think it should wherever all other pam modules are usually put.

Christian

Bug#908223: Bug#908192

2018-10-22 Thread Christian Brauner 
On Mon, Oct 22, 2018 at 02:29:19PM +0200, Pierre-Elliott Bécue wrote:
> Cc-ing Christian as he proposed the patch.
> 
> Le jeudi 18 octobre 2018 à 14:32:12+0200, Matthias Heinz a écrit :
> > Hi,
> > 
> > I've tried applying the patch to the 2.0.9 source. Unfortunately there have 
> > been more changes to conf.c since the release of lxc 2.0.9 and this patch 
> > wont 
> > apply without applying these changes as well.
> 
> What amount of patches would it represent? Would it be relevant to consider
> updating lxc in buster to a newer release?

You should definitely consider upgrading to 3.0.0 it will be a huge
improvement in so many ways.
But I understand that it is work although this might help you :)

https://lists.linuxcontainers.org/pipermail/lxc-devel/2018-April/017663.html

Christian

> 
> Cheers,
> 
> -- 
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.

Bug#908223: Bug#908192

2018-10-22 Thread Christian Brauner 
On Mon, Oct 22, 2018 at 02:29:19PM +0200, Pierre-Elliott Bécue wrote:
> Cc-ing Christian as he proposed the patch.
> 
> Le jeudi 18 octobre 2018 à 14:32:12+0200, Matthias Heinz a écrit :
> > Hi,
> > 
> > I've tried applying the patch to the 2.0.9 source. Unfortunately there have 
> > been more changes to conf.c since the release of lxc 2.0.9 and this patch 
> > wont 
> > apply without applying these changes as well.

So, let me make your life easier by appending a patch on top of 2.0.9.
:)

Christian

> 
> What amount of patches would it represent? Would it be relevant to consider
> updating lxc in buster to a newer release?
> 
> Cheers,
> 
> -- 
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.
>From 8991fdfa9401da4803fb932786b449d3f32ca07c Mon Sep 17 00:00:00 2001
From: Christian Brauner 
Date: Mon, 22 Oct 2018 16:30:49 +0200
Subject: [PATCH] autodev: adapt to changes in Linux 4.18

Starting with commit
55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
Linux will allow mknod() in user namespaces for userns root if CAP_MKNOD is
available.
However, these device nodes are useless since

static struct super_block *alloc_super(struct file_system_type *type, int flags,
   struct user_namespace *user_ns)
{
/*  */

if (s->s_user_ns != _user_ns)
s->s_iflags |= SB_I_NODEV;

/*  */
}

will set the SB_I_NODEV flag on the filesystem. When a device node created in
non-init userns is open()ed the call chain will hit:

bool may_open_dev(const struct path *path)
{
return !(path->mnt->mnt_flags & MNT_NODEV) &&
!(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
}

which will cause an EPERM because the device node is located on an fs
owned by non-init-userns and thus doesn't grant access to device nodes due to
SB_I_NODEV.

The solution is straightforward. Unless you're real root you should bind-mount
device nodes.

Signed-off-by: Christian Brauner 
---
 src/lxc/conf.c | 127 +++--
 1 file changed, 81 insertions(+), 46 deletions(-)

diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 91816beb..384138ec 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -1130,32 +1130,41 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
 	return 0;
 }
 
-struct lxc_devs {
+struct lxc_device_node {
 	const char *name;
-	mode_t mode;
-	int maj;
-	int min;
+	const mode_t mode;
+	const int maj;
+	const int min;
 };
 
-static const struct lxc_devs lxc_devs[] = {
-	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
-	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
+static const struct lxc_device_node lxc_devices[] = {
 	{ "full",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 7 },
-	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
+	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
 	{ "random",  S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 8 },
 	{ "tty", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 5, 0 },
+	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
+	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
+};
+
+
+
+enum {
+	LXC_DEVNODE_BIND,
+	LXC_DEVNODE_MKNOD,
+	LXC_DEVNODE_PARTIAL,
+	LXC_DEVNODE_OPEN,
 };
 
 static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
 {
-	int ret;
-	char path[MAXPATHLEN];
-	int i;
+	int i, ret;
+	char path[PATH_MAX];
 	mode_t cmask;
+	int use_mknod = LXC_DEVNODE_MKNOD;
 
-	ret = snprintf(path, MAXPATHLEN, "%s/dev",
+	ret = snprintf(path, PATH_MAX, "%s/dev",
 		   rootfs->path ? rootfs->mount : "");
-	if (ret < 0 || ret >= MAXPATHLEN)
+	if (ret < 0 || ret >= PATH_MAX)
 		return -1;
 
 	/* ignore, just don't try to fill in */
@@ -1165,53 +1174,79 @@ static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
 	INFO("Populating \"/dev\"");
 
 	cmask = umask(S_IXUSR | S_IXGRP | S_IXOTH);
-	for (i = 0; i < sizeof(lxc_devs) / sizeof(lxc_devs[0]); i++) {
-		const struct lxc_devs *d = _devs[i];
+	for (i = 0; i < sizeof(lxc_devices) / sizeof(lxc_devices[0]); i++) {
+		char hostpath[PATH_MAX];
+		const struct lxc_device_node *device = _devices[i];
 
-		ret = snprintf(path, MAXPATHLEN, "%s/dev/%s",
-			   rootfs->path ? rootfs->mount : "", d->name);
-		if (ret < 0 || ret >= MAXPATHLEN)
+		ret = snprintf(path, PATH_MAX, "%s/dev/%s",
+			   rootfs->path ? rootfs->mount : "", device->name);
+		if (ret < 0 || ret >= PATH_MAX)
 			return -1;
 
-		ret = mknod(path, d->mode, makedev(d->maj, d->min));

Bug#911509: Update to libcap2.26

2018-10-21 Thread Christian Brauner 
Package: libcap2
Version: 1:2.25-1
Severity: normal

Hey everyone,

We recently pushed support for ambient capabilities and namespaces
filesystem capabilities
to libcap2 [1]. Together with Andrew Morgan, Serge Hallyn and I have
released a version 2.26
of libcap2. Note that libcap2 has moved to a new location [2]

The 2.26 release can be downloaded from [3].

Please update to the new version!

[1]: 
https://sites.google.com/site/fullycapable/release-notes-for-libcap/pre-releasenotesfor226
[2]: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/
[3]: 
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/snapshot/libcap-2.26.tar.gz

Thanks!
Christian

Bug#908223: Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)

2018-10-14 Thread Christian Brauner 
On Sat, Oct 13, 2018 at 10:26:57PM +0200, Salvatore Bonaccorso wrote:
> control: 908192 blocked by 908223
> Control: tag 908192 + wontfix
> 
> Hi Christian,
> 
> On Tue, Oct 09, 2018 at 02:06:09AM +0200, Christian Brauner wrote:
> > On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso
> >  wrote:
> > > Hi,
> > >
> > > On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote:
> > > >
> > > > Is it also reverted/back port to Debian?
> > > > Because I still have this problem.
> > >
> > > it has not yet been reverted upstream, the discussion got stuck here:
> > 
> > Hey, I'm one of the ACKers of the original patch and the author
> > of the revert. The kernel patch that broke userspace won't be reverted 
> > upstream.
> > However, I'm also a LXC maintainer and I have fixed LXC upstream to handle
> > 4.18 kernels. The relevant commits are:
> > 
> > master:
> > https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052
> > https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156
> > 
> > stable-3.0:
> > https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf
> > 
> > I haven't done a backport of this to stable-2.0 yet. So far there weren't
> > any complains for that one.
> 
> Thanks for your followup, much appreciated. The repsective bug report
> for LXC itself is #908223 where it then should be fixed.

Thanks. :)

> 
> I'm going to mark #908192 as wontfix for the kernel side. Is it
> planned to backport a fix for stable-2.0?

Just took care of that. I'm appending the commit here but it is
available upstream in the stable-2.0 branch too:

https://github.com/lxc/lxc/commit/db4219603946649474b5cb7915dbd6c17ec728f0

Christian
From db4219603946649474b5cb7915dbd6c17ec728f0 Mon Sep 17 00:00:00 2001
From: Christian Brauner 
Date: Sun, 14 Oct 2018 11:42:29 +0200
Subject: [PATCH] autodev: adapt to changes in Linux 4.18

Starting with commit
55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
Linux will allow mknod() in user namespaces for userns root if CAP_MKNOD is
available.
However, these device nodes are useless since

static struct super_block *alloc_super(struct file_system_type *type, int flags,
   struct user_namespace *user_ns)
{
/*  */

if (s->s_user_ns != _user_ns)
s->s_iflags |= SB_I_NODEV;

/*  */
}

will set the SB_I_NODEV flag on the filesystem. When a device node created in
non-init userns is open()ed the call chain will hit:

bool may_open_dev(const struct path *path)
{
return !(path->mnt->mnt_flags & MNT_NODEV) &&
!(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
}

which will cause an EPERM because the device node is located on an fs
owned by non-init-userns and thus doesn't grant access to device nodes due to
SB_I_NODEV.

This commit enables LXC to deal with such kernels.

Signed-off-by: Christian Brauner 
---
 src/lxc/conf.c | 116 +
 1 file changed, 78 insertions(+), 38 deletions(-)

diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 09acc34a..e9bed5cb 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -989,6 +989,7 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
 	int ret;
 	size_t clen;
 	char *path;
+	mode_t cur_mask;
 
 	INFO("Preparing \"/dev\"");
 
@@ -1000,37 +1001,45 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
 	if (ret < 0 || (size_t)ret >= clen)
 		return -1;
 
-	if (!dir_exists(path)) {
-		WARN("\"/dev\" directory does not exist. Proceeding without "
-		 "autodev being set up");
-		return 0;
+	cur_mask = umask(S_IXUSR | S_IXGRP | S_IXOTH);
+	ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+	if (ret < 0 && errno != EEXIST) {
+		SYSERROR("Failed to create \"/dev\" directory");
+		ret = -errno;
+		goto reset_umask;
 	}
 
 	ret = safe_mount("none", path, "tmpfs", 0, "size=50,mode=755",
 			 rootfs->path ? rootfs->mount : NULL);
 	if (ret < 0) {
 		SYSERROR("Failed to mount tmpfs on \"%s\"", path);
-		return -1;
+		goto reset_umask;
 	}
-	INFO("Mounted tmpfs on \"%s\"", path);
+	TRACE("Mounted tmpfs on \"%s\"", path);
 
 	ret = snprintf(path, clen, "%s/dev/pts", rootfs->path ? rootfs->mount : "");
-	if (ret < 0 || (size_t)ret >= clen)
-		return -1;
+	if (ret < 0 || (size_t)ret >= clen) {
+		ret = -1;
+		goto reset_umask;
+	}
 
 	/* If we are running on a devtmpfs mapping, dev/pts may already exist.
 	 * If not, then creat

Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)

2018-10-08 Thread Christian Brauner 
On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso
 wrote:
> Hi,
>
> On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote:
> >
> > Is it also reverted/back port to Debian?
> > Because I still have this problem.
>
> it has not yet been reverted upstream, the discussion got stuck here:

Hey, I'm one of the ACKers of the original patch and the author
of the revert. The kernel patch that broke userspace won't be reverted upstream.
However, I'm also a LXC maintainer and I have fixed LXC upstream to handle
4.18 kernels. The relevant commits are:

master:
https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052
https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156

stable-3.0:
https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf

I haven't done a backport of this to stable-2.0 yet. So far there weren't
any complains for that one.

Christian

Bug#812127: login: wrong German error message

2017-01-20 Thread Christian Brauner 
So If I may weigh in as a native speaker. While

"Arbeit ohne effektive root-Rechte keinesfalls möglich."

as Helge suggested is possible it is still a little confusing.
I'd simply use

"Arbeit one effektive root-Recht nicht möglich."

the sassy spirit of "cannot possibly work without" won't be captured
by this but it is clearer and frankly, the "cannot possibly work without"
doesn't add a lot of value. :)

Christian

Bug#839843: /usr/bin/lxc-create: Ran rm -rf on an entire filesystem after failing to create a container

2016-10-28 Thread Christian Brauner 
On Sat, Oct 29, 2016 at 12:38:40AM +0200, Christian Brauner wrote:
> On Wed, 05 Oct 2016 13:25:18 -0400 Matthew Gabeler-Lee
> <chee...@fastcat.org> wrote:
> > Package: lxc
> > Version: 1:2.0.4-1
> > Severity: normal
> > File: /usr/bin/lxc-create
> >
> > I ran lxc-create to setup an image, and realized I had given it the wrong
> > arguments (wrong distro version, nothing dramatic), so I stopped it with
> > Ctrl-C and cleaned up the partial directory it left behind.
> >
> > Some time later, while in the process of setting up the container created
> > from using the correct arguments, I noticed many many things going wrong.
> > As I started to go WTF, this pops out on the console used for the original
> > incorrect lxc-create:
> >
> > lxc-destroy: utils.c: _recursive_rmdir: 170 _recursive_rmdir: failed to 
> > delete /scratch
> > lxc-destroy: lxccontainer.c: container_destroy: 2384 Error destroying 
> > rootfs for centos7-32bit-lxc
> > Container is not defined
> > exiting...
> >
> > It ran rm -rf on the ENTIRE FILESYSTEM CONTAINING ALL OF MY LXC IMAGES.
> >
> > Instead of doing an rm -rf on the container, it tried to do an rm -rf of the
> > directory in which the container was created, and since it had to be run as
> > root to create the container, it was pretty $#!%$ successful.
> >
> > reportbug wants me to quote chapter and verse from the policy manual to mark
> > this as a serious bug, but "don't rm -rf the entire OS" is so blatantly
> > obvious that there is no specific policy entry to reference.
> >
> >
> > -- System Information:
> > Debian Release: stretch/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages lxc depends on:
> > ii  init-system-helpers  1.45
> > ii  libapparmor1 2.10.95-4+b1
> > ii  libc62.24-3
> > ii  libcap2  1:2.25-1
> > ii  liblxc1  1:2.0.4-1
> > ii  libseccomp2  2.3.1-2
> > ii  libselinux1  2.5-3
> > ii  python3  3.5.1-4
> > pn  python3:any  
> >
> > Versions of packages lxc recommends:
> > ii  bridge-utils  1.5-9
> > pn  cgmanager 
> > pn  debootstrap   
> > ii  dirmngr   2.1.15-3
> > ii  dnsmasq-base  2.76-4
> > ii  gnupg 2.1.15-3
> 
> Hi,
> 
> Can you please specify the exact commands you used to create the container,
> and the commands you used to clean up the partial directory. The
> partial directory
> should usually be cleaned up by LXC itself. So I'm wondering if this
> has anything
> to do with it. If it's not too much trouble, could you also file a bug against
> https://github.com/lxc/lxc and link in this one here?
> 
> Christian

On second look, there is something that confuses me about this bug report:
You said that you ran lxc-create and then Ctrl+Ced it and then:

> > As I started to go WTF, this pops out on the console used for the original
> > incorrect lxc-create:
> >
> > lxc-destroy: utils.c: _recursive_rmdir: 170 _recursive_rmdir: failed to 
> > delete /scratch
> > lxc-destroy: lxccontainer.c: container_destroy: 2384 Error destroying 
> > rootfs for centos7-32bit-lxc
> > Container is not defined
> > exiting...

This confuses me as the output can only come from running lxc-destroy. So you
must have called the lxc-destroy command. lxc-create would not cause this error
message to be printed. Again, to have any idea of what could possibly cause this
we need to know the exact commands you used.

Christian

Bug#839843: /usr/bin/lxc-create: Ran rm -rf on an entire filesystem after failing to create a container

2016-10-28 Thread Christian Brauner 
On Wed, 05 Oct 2016 13:25:18 -0400 Matthew Gabeler-Lee
 wrote:
> Package: lxc
> Version: 1:2.0.4-1
> Severity: normal
> File: /usr/bin/lxc-create
>
> I ran lxc-create to setup an image, and realized I had given it the wrong
> arguments (wrong distro version, nothing dramatic), so I stopped it with
> Ctrl-C and cleaned up the partial directory it left behind.
>
> Some time later, while in the process of setting up the container created
> from using the correct arguments, I noticed many many things going wrong.
> As I started to go WTF, this pops out on the console used for the original
> incorrect lxc-create:
>
> lxc-destroy: utils.c: _recursive_rmdir: 170 _recursive_rmdir: failed to 
> delete /scratch
> lxc-destroy: lxccontainer.c: container_destroy: 2384 Error destroying rootfs 
> for centos7-32bit-lxc
> Container is not defined
> exiting...
>
> It ran rm -rf on the ENTIRE FILESYSTEM CONTAINING ALL OF MY LXC IMAGES.
>
> Instead of doing an rm -rf on the container, it tried to do an rm -rf of the
> directory in which the container was created, and since it had to be run as
> root to create the container, it was pretty $#!%$ successful.
>
> reportbug wants me to quote chapter and verse from the policy manual to mark
> this as a serious bug, but "don't rm -rf the entire OS" is so blatantly
> obvious that there is no specific policy entry to reference.
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages lxc depends on:
> ii  init-system-helpers  1.45
> ii  libapparmor1 2.10.95-4+b1
> ii  libc62.24-3
> ii  libcap2  1:2.25-1
> ii  liblxc1  1:2.0.4-1
> ii  libseccomp2  2.3.1-2
> ii  libselinux1  2.5-3
> ii  python3  3.5.1-4
> pn  python3:any  
>
> Versions of packages lxc recommends:
> ii  bridge-utils  1.5-9
> pn  cgmanager 
> pn  debootstrap   
> ii  dirmngr   2.1.15-3
> ii  dnsmasq-base  2.76-4
> ii  gnupg 2.1.15-3

Hi,

Can you please specify the exact commands you used to create the container,
and the commands you used to clean up the partial directory. The
partial directory
should usually be cleaned up by LXC itself. So I'm wondering if this
has anything
to do with it. If it's not too much trouble, could you also file a bug against
https://github.com/lxc/lxc and link in this one here?

Christian