Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
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 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. > >
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
Hi Johannes,
On Fri, 15 Oct 2021 20:24:12 +0200
Johannes Schauer Marin Rodrigues wrote:
> Hi Michael & Glenn,
>
> On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl 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
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
Hi Michael & Glenn,
On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl 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
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
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
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 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. 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.
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.
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl 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
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
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? 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. Anyway, this needs discussion first, before you actually start such a mass bug filing Michael [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=development%40efficientek.com OpenPGP_signature Description: OpenPGP digital signature
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
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? OpenPGP_signature Description: OpenPGP digital signature
Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT
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. Glenn
