Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT

[Glenn Washburn]

Hi Johannes,

On Fri, 15 Oct 2021 20:24:12 +0200
Johannes Schauer Marin Rodrigues <josch at debian.org> wrote:

> Hi Michael & Glenn,
> 
> On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl <biebl at debian.org> wrote:
> > Am 15.10.21 um 11:14 schrieb Michael Biebl:
> > > Am 15.10.21 um 07:53 schrieb Glenn Washburn:
> > >> Probably the easiest solution would be to exit early from the post install
> > >> if the current user is not root. There's probably a more subtle fix that
> > >> preserves more functionality (eg. maybe updating the hwdb in PKG_ROOT?),
> > >> what ever gets the post install to not fail in this scenario works for me.
> > > 
> > > Package installations need to be done as root.
> > > I don't think the package would benefit if we'd litter the maintainer 
> > > scripts with id checks.
> > > 
> > > Please elobare what the use case is here?
> > 
> > I notice that you filed multiple bugs against various packages [1].
> > I don't think this is particularly helpful as long as dpkg doesn't 
> > officially support installations as non-root.
> > 
> > If you want to allow non-root installations, then this needs to be 
> > discussed with the dpkg maintainer and ideally on debian-devel.
> > While this might be a laudable goal, my guess is that with the way packages
> > are built today, this is not (easily) possible.
> 
> Helmut just made me aware of this bug as well as few others by Glenn that talk
> about "PKG_ROOT" and asked me to follow up on the topic. Assuming that
> "PKG_ROOT" is a typo and actually "DPKG_ROOT" is meant (Glenn, could you
> clarify?), then it is important to know that DPKG_ROOT is about root as in the
> root path ("/") and not as in the root user. The DPKG_ROOT variable that is set

Yes, I meant DPKG_ROOT.

> for maintainer scripts if dpkg is run with --root and
> --force-script-chrootless. Helmut and I are working on making the Essential:yes
> package set work with DPKG_ROOT and we have submitted patches for all source
> packages that are still missing support for it and we have a salsa CI pipeline
> that makes sure that our patches allow a bit-by-bit identical chroot compared
> to installations without DPKG_ROOT:
> https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Great news!

> 
> While running dpkg with --root and --force-script-chrootless avoids the
> chroot() call and thus, allows installing packages without the root user in
> theory, the DPKG_ROOT mechanism and the avoidance of the chroot() was *not*
> added to dpkg so that packages can be installed as a user other than root. The

I never claimed it was. I suspect your email was written having not
read my response because I address this. And do not make this claim
about DPKG_ROOT. I know that it is for installing in alternate root (/)
directories, and is an orthagonal concept to the root user. This is why
the title of the bug is phrased with an and, indicating that they are
separate things.

> DPKG_ROOT mechanism exists because it allows creating foreign architecture
> chroots for architectures that do not have qemu support yet or for which
> emulation support is too slow. So DPKG_ROOT is something that helps us with
> handling chroots for foreign architectures, bootstrapping Debian as well as
> using Debian in an embedded systems context.

I'm curious what you think about the UML use case that I laid out in my
response to Michael.

> I agree with what Michael already wrote above. Glenn, before you open bugs
> against a number of packages, please explain your use-case to a wider audience.
> Maybe on the debian-devel mailing list. Without more information, I don't see a
> use-case of being able to install packages without being the root user. 

Ok. To the extent that packages do not respect DPKG_ROOT, I consider
that a bug of the individual package (some packages do respect
DPKG_ROOT and most don't need to care). Does Debian has an official
policy around this? Like perhaps explicitly saying that packages may
ignore DPKG_ROOT? Even if it does, the bug falls into the wishlist
category. So I'm still failing to see how the bugs I submitted should
not have been submitted.

> For
> cases where you still want to do that, there is fakeroot and there are Linux
> user namespaces. I maintain a debootstrap alternative called mmdebstrap which
> allows one to create a chroot without being root that makes use of fakeroot and
> unshare. So I can confirm that it is already possible to run dpkg --install
> without being the root user and I currently don't see a reason why adding
> support of running maintainer scripts without being uid 0 would be necessary in
> practice.

I'll have to take a look, this is the first I've heard of this package.
However, neither are commonly installed on systems and aren't installed
on the system that I have an unprivileged account on. dpkg itself has
no issue with running as a non-root user, the issues are with the
packages themselves. As I mention in my other response, I've created a
wrapper script that allows installing to arbitrary user-controlled
directories with commonly installed tools on debian-based systems. Yes,
it does rely on DPKG_ROOT working where needed.

Correct me if I'm wrong, but I need certain privileges to use the
unshare system call, right? I just ran "unshare -m <file> bash" and I
get permission denied. I see in strace the log message:

  unshare(CLONE_NEWNS) = -1 EPERM (Operation not permitted)

> 
> Glenn, if you want to help with DPKG_ROOT, you are welcome to do so! Just write
> patches and submit merge requests to the salsa repository linked above. After
> your patches are tested and show that they result in a bit-by-bit identical
> chroot, you can open a bug against the respective source packages with a
> working patch.

Ok, I'll consider it. I mostly wanted to document the issue I was
seeing so they might be fixed in the next decade. Not believing I'd
have a fix any time soon, I'm working off the assumption that I'll need
work arounds.

My response to Michael may clear up uncertainties and misconceptions.
I'm looking forward to continuing the discussion based.

> 
> Thanks!
> 
> cheers, josch

Glenn