On Sun, 17 Sept 2023 at 00:12, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > Aside from more practical considerations, shipping /var content in > > packages is problematic because it's supposed to be local variable data, > > that can be removed without breaking a system. > > Unless I'm missing something, including the directory in the deb won't > make any difference here. dpkg won't break if a directory that was > included in the package is deleted. It would show as an inconsistency if > someone checked the file system against the dpkg database, but as soon as > systemd-tmpfiles runs, it will create the directory again and fix the > inconsistency, so I don't see what problems that would create.
That was a remark about the concept itself, independently of tmpfiles - variable data is variable data, and static data is static data. Having variable data among static package content sounds conceptually wrong to me, simply from a high-level design perspective. > > More practically, one of the purposes of the hermetic-usr pattern is to > > allow several modernizations. The easiest one to achieve is to create > > /var/ on firstboot, and encrypt it against the tpm, so that it can be > > enabled by default, always, so we can't have packages ship and expect > > content in /var from their packages. > > (I am a little confused by this wording, but I think what you're saying is > that /usr is encrypted and read-only, and /var is recreated on each boot. > That at least is my understanding of the pattern that you're trying to > enable.) Let me clarify, here I meant something much simpler - the image installed is a 'normal' one, with r/w root and managed by apt as usual (ie: not immutable image-based) but with a repart.d snippet that causes a new /var to be created on-the-fly on first boot if missing, with tpm-bound encryption (and similar treatment for /home, although unrelated here). This is a very low-hanging fruit of a pattern that would allow to achieve decent local data protection on an otherwise pretty much vanilla setup. But if you need to ship /var from packages, then it goes out of the window. In a sense, for the immutable /usr case it gets easier - you just don't ship a package manager at all, and then you can do all the mangling you want when building the image, as consistency no longer matters, and you don't install/upgrade by definition. But I strongly believe we need to do some serious steps forward in the security-by-default aspects of all flavours, including the 'vanilla' ones, where this consistency matters a lot, for obvious reasons - you do upgrades/installs on those. And yes, I would hope to have a concrete proposal for encrypting by default to submit to the project for at least something like this for Trixie, once more pieces have fallen into place. All mainstream distributions are looking into some variation of this. It is way past time Linux caught up with OSX and Windows on these aspects, and it would be great if for once Debian wasn't left behind as usual. > > On top of that, as you mentioned already things will inevitably get out > > of sync, and one will have to duplicate everything. > > One would need to duplicate empty directories in /var (that don't have > dynamic ownership). I'm dubious that's a significant burden (it's two or > three lines in debian/rules), but if it is, one could even automate this > in debhelper by parsing tmpfiles.d if one really wanted to. The main > thing that could get out of sync is the ownership, which is indeed not > ideal, but I'm also not sure it's going to cause major problems even if > people do get it wrong. I was trying to remember if dpkg changes > directory (as opposed to file) ownership if it sees a directory owned by > an unexpected user. I kind of think it doesn't, but I'm not sure about > that. > > The benefit we gain from this is attribution of the directories in the > dpkg database, which is useful (although I understand that one can argue > about how useful). I don't think it is particularly useful, and mixing package content with variable data smells like trouble to me. I'd much rather finish the factory reset workstream for lifetime management, so that tmpfiles can handle tmpfiles purges, without needing to involve dpkg. We are working on that. This means that tmpfiles.d would be able to both create the files/dirs when needed, and remove them when unneeded, ie on purge - as far as I can tell, that would be the only useful thing that a dpkg integration would provide. I am pretty sure running checksums on local variable data would be a pretty useless exercise given, well, it's variable. Or was there anything else aside from these two aspects? To do the tmpfiles purge/reset I have two WIP PRs, one against sd-tmpfiles, and one against debhelper. I need to pick them up again and finish that, and I am aiming to do so within the next couple of months. > So... I think the answer to my question of whether this will interfere > with your use case is no? I understand that you don't want to do it, and > expected that, and that opinion is important for the discussion, but I'm > also trying to figure out if it will *break* anything. On the contrary I suspect it would break things or at the very least get in the way, as explained above. Of course I haven't tested this as we aren't there yet, so can't be 100% sure. But from what I've seen from some experiments, expectations around /var being fixed and package-managed is already creating some headaches, and requiring workarounds.
