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

[Glenn Washburn]

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:
> > Control: tags -1 + moreinfo
> > 
> > Am 15.10.21 um 07:53 schrieb Glenn Washburn:
> >> Package: udev
> >> Version: 247.3-5
> >>
> >> 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?

Package installation does not need to be done as root. In fact, many
packages install just fine as a non-root user (even if they were never
intended to be installed that way). In fact, dpkg and apt/apt-get allow
this, though its not a common mode of operation. And this is something
commonly requested. If you search on the various stack exchange sites
and google you'll see lots of people wanting to do non-root installs.

My use case is that I have an unprivileged account on a debian system
and I want to install packages. To avoid dependency hell, I'd like to
use apt/apt-get to figure out the dependencies and download them. If I
already have that, then it would be nice to have apt/apt-get install the
packages via dpkg, not least because I can create a wrapper that allows
other scripts to transparently install as non-root and to a directory
of my choosing, which I've already created.

Now one of the most straight forward ways to solve this problem is to
use chroot to install into another root. However, this is not an
option, as chroot requires privileges I don't have.

And yes there are other ways to skin this cat, for instance, the most
obvious alternative is to use dpkg-deb -X to install to an alternate
root. You still have the dependency hell issue, but that's not
insurmountable by using apt-get -s and parsing the output. The thing
is, this method is more hacky, potentially more error-prone, and
results in something less featureful (eg. dpkg-query doesn't work).

The one thing the dpkg-deb -X method has going for it, is that it does
not run post install scripts. So I wouldn't get the errors I'm getting
because, unfortunately, there isn't a way (that I know of) to tell dpkg
to not run post install scripts on install. But not running post
install also a strike against it. There may be some useful actions
taken in those scripts in making the installed package useful/runnable.
From what I've seen, this is generally not the case, but there's a lot
of packages I haven't looked at.

And my use case is also, not just wanting to install to be run as a
regular user. I want to build a directory tree that will be overlayed
on to the real root in a UML instance. If I didn't need to run the
installed binaries outside the UML, then the propose solution would
work as is. However, because I need to run some binaries outsdie the
UML, I'll need to fix broken symlinks pointing to an absolute path in
the alternate root, which also isn't hard to do. This mostly applied to
unversioned library paths which point to a path with the version (I
believe mostly used in *-dev packages). Something to explore might be
to have all symlink destinations be relative to their location (see
realpath --relative-to).

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

Can you point me to public documentation confirming this point of view?
My evidence to the contrary is the man page dpkg(1) itself. Under the
--force-* options:

  not-root: Try to (de)install things even when not root.

and

  script-chrootless: Run maintainer scripts without chroot(2)ing into
  instdir even if the package does not support this mode of operation
  (since dpkg 1.18.5).

More evidence for my case can be found in man 5 dpkg.cfg where it
lists several locations that dpkg looks for configuration files. One is
"~/.dpkg.cfg". Now why would it search for a configuration file in the
home directory of a user if running as a non-root user was not
officially allowable?

I think what you really mean is that most packages were not written
with this use case in mind, and I would find that credible. Most don't
really need to have been, but a few do.
> 
> 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.

Dpkg supports non-root installations perfectly fine and as mentioned I
have a working wrapper script called apt-user, which configures things
such that package installs can be done to arbitrary directories by
non-root users. It can be used to transparently replace uses of
apt/apt-get in other applications. Of course, the user much have the
correct permissions to install to the given path, but that's not dpkg's
resonsibility.

> 
> Anyway, this needs discussion first, before you actually start such a 
> mass bug filing

5 bugs may appear as a mass bug filing, but out of thousands of
packages I'd say its pretty small. So I disagree with that
characterization. I was filing bugs against packages that had issues
installing non-root for a set of packages and their dependencies (about
50) that I needed to install. I'm not going through all packages to see
which are offending. I may file a few more package specific bugs as
needed, but I think I've got my use case mostly covered.

> 
> Michael
> 
> [1] 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=development%40efficientek.com
> 
> 

Glenn