David Kalnischkies <da...@kalnischkies.de> (2015-11-28):
> Mhhhhhh. apt is run as root (as we don't reach this codepath with uid !=
> 0), but it has all the groups of kibi and a setgroups is silently
> ignored… wtf…

Hmmm, there's fakeroot in the middle!

| ifneq ($(shell id -u),0)
|   ROOTCMD ?= fakeroot
| endif
| 
| # Useful command sequences
| define submake
|   $(ROOTCMD) $(MAKE) --no-print-directory -j1
| endef

which probably explains why copying/pasting the command line worked,
as opposed to running make and submakes, the last ones being under
fakeroot?

> The code is if someone wants to look:
> https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264
> I will go to bed now, maybe I have an epiphany tomorrow.
> (or manage to reproduce this for a start)
> 
> 
> > While I've been experimenting with adding/removing myself from the said
> > groups, I'm noticed this a few times, without being able to figure out
> > what exactly causes this…
> > | W: No sandbox user '_apt' on the system, can not drop privileges
> > 
> > In which case, going back to apt.git and "sudo debi -u" to reinstall all
> > packages I've built seems to fix the issue.
> 
> As mentioned briefly schroot copies users & groups from your host
> system, so if your host system has no _apt user, the _apt user in your
> schroot will "disappear" next time it is copied over.

Ah, right. That explains why running adduser/deluser from within/outside
the chroot made little difference, given the culprit was my leaving and
re-entering the chroot session… I'm not sure how buildds are set up, and
whether _apt will stick there (not really a reasonable hour to go look it
up though); there are different flavours/profiles in the sbuild and
schroot worlds anyway, so hopefully that's going to “just work”.

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature

Reply via email to