Bug#651237: lxc.cap.drop in config provokes erroneous start of container

[Marcus Osdoba]

Package: lxc
Version: 0.7.5-12
Severity: normal
Tags: sid

Hi,
I created an squeeze container using lxc-debian template from latest sid. The
generated config includs a cap-driver setting.

With this setting enabled, the container didn't came up cleanly:
***@thinkpad:# grep cap squeeze-debian/config
lxc.cap.drop = sys_admin sys_module mac_admin
mac_override
***@thinkpad:# lxc-start -n squeeze-debian
Mount failed for selinuxfs on /selinux: Operation not permitted
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
mount: permission denied
mkdir: cannot create directory `/lib/init/rw/sendsigs.omit.d/': File exists
mount: permission denied
hostname: you must be root to change the host name
[...]

WithOUT this entry, the container "booted" as expected:
***@thinkpad:# grep cap squeeze-debian/config
#lxc.cap.drop = sys_admin sys_module mac_admin
mac_override
***@thinkpad:/home/ossy/lxcontainer# lxc-start -n squeeze-debian
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Cleaning up ifupdown....
Setting up networking....
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.17.2
done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
[..]

The linux-container package was successfully installed inside the squeeze
container via chroot.



-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.39-bpo.2-486
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxc depends on:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libcap2 1:2.19-3 support for getting/setting POSIX.

Versions of packages lxc recommends:
ii debootstrap 1.0.26+squeeze1 Bootstrap a basic Debian system
ii libcap2-bin 1:2.19-3 basic utility programs for using c

Versions of packages lxc suggests:
pn lxctl <none> (no description available)

-- debconf information:
lxc/shutdown: stop
lxc/directory: /var/lib/lxc
lxc/title:
lxc/auto: true

[Daniel Baumann]

At least the hostname is not set

no, hostname is set from utsname by lxc; the container itself (through
/etc/init.d/hostname) is not allowed to set it.
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: ***@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/

[Daniel Baumann]

The linux-container package asks for the hostname, too.
So is this necessary, when hostname isn't readable by the container and
set outside anyway?

if you think about it, what does your heart tell you? ;)
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: ***@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/

[Marcus Osdoba]

Post by Daniel Baumann

The linux-container package asks for the hostname, too.
So is this necessary, when hostname isn't readable by the container and
set outside anyway?

if you think about it, what does your heart tell you? ;)

You wouldn't have put it into the linux-container if it wasn't
necessary. But the container is not allowed to see it.

You are the trusted source in this question and on the first view it
looks contrary. Enlight me if you like.

[Marcus Osdoba]

The linux-container package asks for the hostname, too.
So is this necessary, when hostname isn't readable by the container and
set outside anyway?

Sorry for bothering again.

I've tested the recent versions lxc-0.7.5-14 and linux-container_1-3.
The hostname configured by the linux-container package inside the
container is never used when dropping capabilites (which is default) -
because hostname.sh fails.

That's ok when setting uts-name in config, but by default this value is
emtpy and one need to know, that the hostname has to be set there.

For first-contact-users this looks a bit confusing. The container patch
ifupdown_607713.sh explicitly requires hostname.

So I'm just putting this information here for other users.

[Daniel Baumann]

Post by Marcus Osdoba
The hostname configured by the linux-container package inside the
container is never used when dropping capabilites (which is default) -
because hostname.sh fails.

as i said before, that does not matter.

Post by Marcus Osdoba
That's ok when setting uts-name in config, but by default this value is
emtpy and one need to know, that the hostname has to be set there.

no, by utsname is set by default.

Post by Marcus Osdoba
For first-contact-users this looks a bit confusing. The container patch
ifupdown_607713.sh explicitly requires hostname.

no, it does not depend on hostname.
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: ***@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/

[Marcus Osdoba]

Post by Daniel Baumann

Post by Marcus Osdoba
The hostname configured by the linux-container package inside the
container is never used when dropping capabilites (which is default) -
because hostname.sh fails.

as i said before, that does not matter.

Accepted. I ignored the mounting errors - but the hostname stays empty
and I (and possibly other uers, too) expect a valid hostname inside the
container.

Post by Daniel Baumann

Post by Marcus Osdoba
That's ok when setting uts-name in config, but by default this value is
emtpy and one need to know, that the hostname has to be set there.

no, by utsname is set by default.

The utsname is not filled by default. The code sets _NAME in the config
file only, when given by commandline option --name (it's not asked in
the debconf masks).
That's not obvious for most users.

Post by Daniel Baumann

Post by Marcus Osdoba
For first-contact-users this looks a bit confusing. The container patch
ifupdown_607713.sh explicitly requires hostname.

no, it does not depend on hostname.

True. The script does not depend on the hostname, but it makes
ifupdown-clean depending on starting hostname first. Hostname is enable
by default and not disabled by the linux-container package.

Please note, that I don't intend to re-open this bug, I just want to put
information for others here, who are trying to test the lxc package from
Sid. I don't expect an answer.


Just in case, you like to know my latest test results with lxc-0.7.5-14:
(the following lines are a summary of the attached log)
creating the container on a 32bit host with
/usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/squeeze
--> empty utsname in squeeze/config
Root-Password "hallo" wasn't picked up. I needed to change it with
chroot/passwd. I re-tried that on an amd64 host creating a 32bit
container and it was set correctly to "hallo".
Installing the linux-container package via chroot. -> set a hostname
there (the hostname set by linux-container is never seen when starting
the container).
Setting utsname manually in config, resulted in the expected hostname
after starting the container.

So why set the hostname with linux-container pkg, if the dropped caps
disable the ability to read the hostname inside the container?

I'm ok with the dropped caps.
But the missing hostname stays confusing.


Drop me a line, if you dont't like to read my bugreports.

Hopefully you understand what I trying to report, if not, take my
excuses for wasting your time.

[Daniel Baumann]

Post by Marcus Osdoba

Post by Daniel Baumann
as i said before, that does not matter.

Accepted. I ignored the mounting errors - but the hostname stays empty
and I (and possibly other uers, too) expect a valid hostname inside the
container.

no; for the last time.. hostname does get set.

Post by Marcus Osdoba
The utsname is not filled by default. The code sets _NAME in the config
file only, when given by commandline option --name (it's not asked in
the debconf masks).

no; for the last time.. utsname does get set, you can't call lxc-create
without -n, -n is mandatory and lxc-create refused to do anything if -n
is not specified.

Post by Marcus Osdoba
That's not obvious for most users.

***@debian:~# lxc-create -t debian
no container name specified
usage: lxc-create -n <name> [-f configuration] [-t template] [-h] --
[template_options]
***@debian:~#

totally not obvious (sic!).

Post by Marcus Osdoba

Post by Daniel Baumann
no, it does not depend on hostname.

True. The script does not depend on the hostname, but it makes
ifupdown-clean depending on starting hostname first. Hostname is enable
by default and not disabled by the linux-container package.

doesn't matter; ifupdown-clean does not depend on the hostname script
exiting sucessfull (and, eventhough ifupdown-clean does not need
hostname at all, the hostname is set at that point otherwise already
anyways).

Post by Marcus Osdoba
Please note, that I don't intend to re-open this bug, I just want to put
information for others here, who are trying to test the lxc package from
Sid. I don't expect an answer.

you're doing much worse, so far you've constantly putting false
information here that i have to correct so others do not get 'confused'
by your 'findings'.

Post by Marcus Osdoba
(the following lines are a summary of the attached log)
creating the container on a 32bit host with
/usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/squeeze

garbage in, garbage out - no surprise there.

would you finally start using lxc-create as you're supposed to do?

there's a reason the templates are not in /usr/sbin but 'hidden' in
/usr/lib/lxc/templates. no documentation says you can run a template
without lxc-create, and all documentation speaks about lxc-create only.
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: ***@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/

[Marcus Osdoba]

Post by Daniel Baumann
would you finally start using lxc-create as you're supposed to do?
there's a reason the templates are not in /usr/sbin but 'hidden' in
/usr/lib/lxc/templates. no documentation says you can run a template
without lxc-create, and all documentation speaks about lxc-create only.

The debian wiki and all resources linked there, always talk about using:
/usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0

I will correct the information there.

Thanks for pointing out the misunderstanding.

[Daniel Baumann]

Post by Marcus Osdoba
/usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0

unfortunately, it's not possible to track external documentation
(anything outside of the lxc package, that is) and therefore ensure the
quality and "up2date-ness" of it. any help with that is much
appreciated, thanks.

regarding the wiki page, i wasn't aware of its existence. the
information there should be moved to the package itself, so that the
wiki page can be removed entirely (except for the pointer to the
included documentation in the lxc package; patches welcome :).

Post by Marcus Osdoba
Thanks for pointing out the misunderstanding.

it turned out that this would have been spotted much earlier if you
would have listed the exact command you're using in the first place.

a good advice seems to be for future bug reports in general, that you do
make it as easy as possible for the maintainer to understand what you
did and where you experienced problems by starting with the exact
commands that you used.
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: ***@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/

[Marcus Osdoba]

Post by Daniel Baumann

At least the hostname is not set

no, hostname is set from utsname by lxc; the container itself (through
/etc/init.d/hostname) is not allowed to set it.

The linux-container package asks for the hostname, too.
So is this necessary, when hostname isn't readable by the container and
set outside anyway?