[systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?

[Lennart Poettering]

On Mon, 07.01.13 09:36, Colin Walters (walters at verbum.org) wrote:

> 
> On Mon, 2013-01-07 at 15:26 +0100, Lennart Poettering wrote:
> 
> > BTW, Kay and I were thinking about coming up with a simple scheme that
> > could pre-initialize a couple of files in /etc and /var that cannot
> > really sensibly be dropped. For example, UID assignemnts unfortunately
> > cannot be shipped in packages from the distro, they must happen
> > dynamically on the local system, 
> 
> I ship them statically:
> 
> http://git.gnome.org/browse/gnome-ostree-integration/tree/src/lib-passwd
> 
> But I don't have "packages" - there is no ability to dynamically mutate
> your root filesystem while it's running.
> 
> (Note also that gnome-ostree has both /etc/passwd and /lib/passwd, via
>  https://github.com/aperezdc/nss-altfiles )

Ah, this is cool, I think it would make a ton of sense for general
purpose distros to move all the fixed assignments into /usr/lib.

Of course, such a solution only solves half the problem since it cannot
cover for uids allocated for 3rd party packages.

> Well note in the gnome-ostree split-password model, dropping /etc only
> deletes users for /home, not the OS.

So you basically say that stuff you install on gnome-ostree never can
allocate its own UIDs, right?

> But dynamically allocating system users per-boot and ensuring that
> /etc and /var matches would still be interesting.

Uh, yeah, there's still the question out there what to do with fully
dynamic throw-away UIDs, for example so that gdm could allocate a UID
for each seat when showing login prompts dynamically. This is going to
be really hard, since after dropping a UID again one needs a good way to
drop all files and other objects the user created before handing out the
same UID again, and I do not see how we could deal with that properly.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.