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