I've been arch-testing packages on hppa for a while in a complete root chroot. Then I've lost wheel access and was asked to use unprivileged containers. This works for most packages but some packages need major workarounds to map all groups to root (or current user). Can I get wheel access to be able to cover more packages without much changes? Thanks!
slyfox: in a namespace container setup where the stuff inside the container thinks it has root, what doesn't work for you? vapier: at one point you had good tooling to set up namespace-containers for this stuff, but I'm not sure where you had it stashed. Can we get it consistently available on all dev systems? (probably installed w/ the same ansible work I'd been planning for consistent users on these hosts, incl matching UIDs to LDAP for devs).
(In reply to Robin Johnson from comment #1) > slyfox: in a namespace container setup where the stuff inside the container > thinks it has root, what doesn't work for you? Things don't work as-is as long as they try to create non-root-owned files or processes. I usually work things around manually to avoid these cases. The idiosyncrasy of unprivileged linux containers is how host->container UID mapping happens: you cannot map multiple container users to one host user. You can only do one-to-one UID mappings (up to 5 UID ranges with host->container offset specified). For example: - map 100 host users to 100 container users with offset (0-> 1000 , 1 -> 1001, ... 99 -> 1099). This requires host system to provide 100 fresh UIDs in host system: 1001 to 1099. As I understand it this requires root to create unprivileged container. - or map container:root->host:user and leave the rest as-is and try hard not to use non-root users. That's what I use with unshare: $ unshare --user --map-root-user ... Using single UID container:root->host:user mapping means that you need to force everything to run as root in container. Either through mangling of /etc/passwd to set all UIDs to 0 or through other means. For example my make.conf starts as: PORTAGE_USERNAME=root PORTAGE_GRPNAME=root Otherwise portage can't setuid() to portage and can't create files as 'portage' user/group on a filesystem. Other problem examples (all are UID related): - tar can't unpack files as original user specified in tarball. I have to fix ebuilds and eclasses like: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6991c2a4783cd454dd62de04e5bc04b3b9e43249 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a10a1bf072ae90445fb6d238659a799d3bf55375 More fixes pending ruby-gems fixes. - chown in ebuilds usually does not work. I have to keep the following in /etc/portage/bashrc: chown() { :; } fowners() { :; } - Today's attempt to build/install man-db into such container: # emerge -v1 sys-apps/man-db ... chown: changing ownership of '/var/tmp/portage/sys-apps/man-db-2.7.6.1-r2/image//usr/bin/man': Invalid argument chown: changing ownership of '/var/tmp/portage/sys-apps/man-db-2.7.6.1-r2/image//usr/bin/mandb': Invalid argument * emake failed - Some programs refuse to run as UID=0 as they hardcode check against currently running UID=0 for security reasons. And there is no UID to downgrade to.
(In reply to Sergei Trofimovich from comment #2) > (In reply to Robin Johnson from comment #1) > > slyfox: in a namespace container setup where the stuff inside the container > > thinks it has root, what doesn't work for you? > > Things don't work as-is as long as they try to create non-root-owned files > or processes. I usually work things around manually to avoid these cases. > > The idiosyncrasy of unprivileged linux containers is how host->container UID > mapping happens: you cannot map multiple container users to one host user. The unshare tool itself does not support multiple users (specifically it does not support subuid/subuid)). The underlying user namespaces DO support multiple users. I need to dig up the other tooling that can make it easier, but as a trivial example, using Docker to spin up the unprivileged container (notice that --privileged is NOT passed to docker-run): (as non-root user:) # mkdir /tmp/nstest # find /tmp/nstest -ls 1934365 0 drwxr-xr-x 2 robbat2 robbat2 51 May 6 23:36 /tmp/nstest/ # docker run -it --rm \ --mount type=bind,source=/tmp/nstest,destination=/tmp/nstest busybox (inside busybox container now) # install -o 123 -g 456 -m 0644 /dev/null /tmp/nstest/foo # exit (outside container) # find /tmp/nstest -ls 1934365 0 drwxr-xr-x 2 robbat2 robbat2 51 May 6 23:37 /tmp/nstest/ 1934369 0 -rw-r--r-- 1 12345 45678 0 May 6 23:36 /tmp/nstest/foo
(In reply to Robin Johnson from comment #3) > (In reply to Sergei Trofimovich from comment #2) > > (In reply to Robin Johnson from comment #1) > > > slyfox: in a namespace container setup where the stuff inside the container > > > thinks it has root, what doesn't work for you? > > > > Things don't work as-is as long as they try to create non-root-owned files > > or processes. I usually work things around manually to avoid these cases. > > > > The idiosyncrasy of unprivileged linux containers is how host->container UID > > mapping happens: you cannot map multiple container users to one host user. > The unshare tool itself does not support multiple users (specifically it > does not support subuid/subuid)). The underlying user namespaces DO support > multiple users. > > I need to dig up the other tooling that can make it easier, but as a trivial > example, using Docker to spin up the unprivileged container (notice that > --privileged is NOT passed to docker-run): Interesting. I had an impression you could subvert host system if you were able to create SUID binaries with arbitrary UIDs in a container and could control UID offset mapping from the host. And could even read files you could not before by bind-mounting parts of host system into a container. docker seems need a root daemon to do container creation (but maybe it's a remnant of privileged-only containers or a need for subvolume creation): * To use Docker, the Docker daemon must be running as root. To automatically * start the Docker daemon at boot, add Docker to the default runlevel: * rc-update add docker default * Similarly for systemd: * systemctl enable docker.service * * To use Docker as a non-root user, add yourself to the 'docker' group: * usermod -aG docker youruser I'll take a look anyway.
granted!
