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

Fri Oct 15 21:10:57 BST 2021

Hi Glenn,

Quoting Glenn Washburn (2021-10-15 21:39:08)
> > 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.

okay. It is customary to open one bug per issue instead of conflating multiple
problems into a single bug.

> > 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.

User Mode Linux?

> > 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.

Before filing multiple bugs of the same category (a mass bug filing), the issue
should be discussed on the debian-devel mailing list as written up here:

https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#reporting-lots-of-bugs-at-once-mass-bug-filing

> > 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.

mmdebstrap is a single script that you can copy around without installing it.
It just needs apt and dpkg installed.

> dpkg itself has no issue with running as a non-root user, the issues are with
> the packages themselves.

Yes, dpkg can do it. But this is not a question of whether dpkg can do it. This
is a question of policy about whether we want to support installing packages
like that in Debian. More on that below.

> 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.

So you want to have a directory, maybe in your $HOME and fill that directory
with packages in their installed state, right? And you want to be able to do
this without root, right? Try doing this:

mmdebstrap --variant=essential --include=somepkg unstable ./some/directory

This will put essential packages and "somepkg" into ./some/directory.

> 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)

That's why you have to unshare the user namespace first, like this:

    $ lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- /usr/sbin/chroot ./debian-rootfs /bin/bash

Or like this:

    $ unshare --map-root-user -m whoami
    root

> > 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.

The fact that dpkg allows running maintainer scripts without being the root
user is only a necessary but not a sufficient condition to getting maintainer
script in Debian adjusted. I suggest that you bring up the problem on
debian-devel. Though I expect you will get the following counter arguments:

 - filling a directory with several installed packages as non-root user is
   already possible (see above)
 - given that it's already possible, it is not necessary to add additional
   complexity to maintainer scripts
 - even if you install packages into a directory under home, you cannot satisfy
   dependencies with those packages because a lot of software will not have
   that directory in their search paths: think of shared libraries, python
   modules, cmake modules, shared data and so on... So even if you install some
   packages into a different directory, software will usually not know that
   it's there

Another tip: if you want to see change happen in Debian, it is best to come
with patches that you have tested. Maintainers will be very hesitant to spend
time on a project that is not of their interest. One way to make it their
interest is to get project consensus and for that you have to write to the
debian-devel list. This bug is not the right place to discuss the overall merit
of your approach.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20211015/bc0a1003/attachment.sig>