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
signature.asc
Description: signature
