On Sun, Aug 29, 2021 at 11:30:41PM +0100, Colin Watson wrote: > On Sun, Aug 29, 2021 at 11:31:05AM -0700, Russ Allbery wrote: > > Colin Watson <cjwat...@debian.org> writes: > > > I think it's an interesting idea and worth pursuing, but on the face of > > > it it seems that this would end up violating policy 9.2.2: > > > > > "Globally allocated by the Debian project, the same on every Debian > > > system." > > > > > ... because the UID of the _apt user in fact wouldn't be the same on > > > every Debian system, and I can imagine that this might cause trouble > > > somewhere. > > > > My first reaction is that from a strictly Policy perspective you may be > > reading that requirement too strictly. > > Certainly possible, and also it's extremely rare for issues about the > global static range to come up at all so we've never really litigated > the exact boundaries of this text. > > > I would read that as a statement of intention, not a requirement: the > > intent is for this UID to be the same on every Debian system, but this > > may not be the case in practice due to upgrades. (Which seems > > obviously true or we could never add a new user.) > > It's only an issue for users that were already created by some other > package (unless you count the small number of non-system users that > might conflict with any addition, in the absence of "_" prefixes and the > like). > > This is also literally the first reasonably compelling case there's been > for adding a new entry to passwd.master in my time as base-passwd > maintainer (since 2002). > > > That said, it does feel weird to switch to this sort of static allocation > > and not have a migration strategy for existing systems and leave them on > > an old UID. I know that it's not an explicit design goal of the project, > > but I like the idea that continuously upgraded systems will converge on > > the state that they would get if they were newly-installed, and that seems > > valuable for long-term upgrade support. > > > > My intuition is also that the case where a UID change will cause problems, > > namely: > > > > > I'm mostly just worried about users using file:/ or copy:/ methods > > > and having given _apt access to them, they'd break. > > > > is relatively rare (but maybe I'm wrong about this?), so I'm not sure that > > it outweighs the simplicity advantages of converging on the same UID in > > the long run. > > It does feel likely to be rare, but maybe Julian or somebody else on > deity@ can elaborate on whether this is something they've seen much in > the wild.
There are quite a few scenarious like - those file:/ and copy:/ ones. I believe this is a temporary thing, but I don't know when I can rework stuff such that we can run those methods as root and/or open the files inside apt and pass them via fd. OTOH, you might be mounting those repos over untrusted NFS or stuff, and the sandboxing might still be useful - more importantly in the wild long term, is granting access to SSL certificates and passwords to the _apt user only while preventing other users from reading those files. The way these settings work is that you can't know which files to parse before dropping privileges. I think passwords was fixed to read as root, but you can scope SSL cert locations by host name, which breaks stuff. Lots of enterprisey users with like internal CAs or client certs for login to repositories, I suppose. We could ask apt to retrieve the settings for us, but adding more escape hatches to sandboxes doesn't make them stronger. > > A UID migration would also require changing the ownership of (at least) > /var/cache/apt/archives/partial, /var/lib/apt/lists/auxfiles, and > /var/lib/apt/lists/partial. Maybe something like "find /etc/apt > /var/cache/apt /var/lib/apt -user _apt" would make this less fragile, > but it still seems like an awkward thing to be doing in base-passwd's > postinst. Helmut said in the original bug report that "libapt always > chowns it to _apt"; I don't know how reliable this is or whether libapt > does it for all the relevant directories. If it's absolutely reliable > then maaaybe we could skip that step, though it feels a bit risky. it does chown everything it needs to _write_ to. Goal would be to eventually have everything owned by root again and pass fds to the sandboxed processes via socket, to prevent the sandbox escape we have now. But hard. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
