[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#908092: dbus: skip autopkgtest ulimit test when in a container

On Fri, Sep 07, 2018 at 08:46:23PM +0100, Simon McVittie wrote:
> On Wed, 05 Sep 2018 at 22:02:01 -0700, Steve Langasek wrote:
> > This is because armhf is the single architecture on which Ubuntu runs its
> > autopkgtests in containers rather than in VMs, and these are unprivileged
> > containers, which means "root" processes don't actually have the
> > capabilities necessary to re-raise limits after they've been lowered.

> I'm not sure whether such a container should be considered to satisfy the
> needs-root restriction. How much root does/should needs-root guarantee?

FWIW this particular capability restriction hasn't been a problem for any
other needs-root packages before now, that I've seen.

> Perhaps there should be separate restrictions for "needs fully privileged
> root" and "needs unprivileged-container root"? (But I'm not sure which
> one needs-root should be.)

> > I've uploaded the attached patch to Ubuntu in order to have passing tests
> > again on armhf.  I'm not sure if you would consider it sufficiently correct
> > for Debian, since this means we're also skipping this test on privileged
> > containers, but I guess it should be a starting point for discussion.
> Can we probe for the required capability, perhaps with

>     capsh | grep '^Current:.*\<cap_sys_resource\>'

> or something?

Not sure about that syntax, but anyway here's what I see:

# capsh --print | grep ^Current:.*\\bcap_sys_resource\\b
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
# ulimit -n 1024
# ulimit -n 4096
bash: ulimit: open files: cannot modify limit: Operation not permitted

So it looks like the kernel lies about the capability as well.

You could do a probe with sh before running the actual test, e.g.:

  sh -c ulimit -n 1024; ulimit -n 4096' || skip_ulimits

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: PGP signature

Reply to: