[Pkg-sysvinit-devel] init.d/urandom : saving random-seed

[Henrique de Moraes Holschuh]

On Mon, 02 Aug 2010, Christoph Anton Mitterer wrote:
> On Sat, 2010-07-31 at 13:36 -0700, John Denker wrote:
> > > And we should move the seed file to somewhere inside /etc or /lib.  It is as
> > > simple as that.  /var cannot be used for any data you need at early
> > > userspace.
> > 
> > There are strong arguments for _not_ putting the random-seed in /etc
> > or /lib.  There are lots of systems out there which for security 
> > reasons and/or performance reasons have /etc and /lib on permanently
> > readonly partitions.

In this case, the requirement is that the seed MUST be available to early
userspace.  There are *absolute* requirements for early userspace, which
trump anything else, including the FHS.  When you cannot meet those
requirements, you have to abandon the idea of doing it in early userspace.
It is THAT simple.

Early userspace means you have a read-only / and some virtual filesystems
mounted, a partial /dev (probably on tmpfs), and that's about it.

So anything used by early userspace *must* go in /.  The only hierarchies
that are always in / (for *Debian*) are:

/etc
/bin
/sbin
/lib* (/lib32, /lib64...)

We can certainly create some other toplevel hierarchy which is required to
be in /.  But that is genearally considered an worse option than adding the
hierarchy inside /lib or /etc.

Also, if you want read-only /lib or /etc, you want read-only /.  This is
completely incompatible with file-based random seed persistence done right.
You will have to do away with the file-based approach, and use a hardware
TRNG that can work in early boot, just like a Live-DVD/Live-CD would.

Or you can edit the scripts to have / remounted read-write for the window
required to refresh the seed files at late boot and shutdown.

read-only / is also not a supported configuration, so it is your problem to
make sure your system behaves sanely with read-only /.  We *do* support
Live-CD-style schemes, though (where writes are lost upon reboot), so we can
certainly get rng-tools migrated to / to help those.

> I'm not sure whether it's really strictly the case that /var is
> completely local. It might be in Debian, but AFAIU the FHS

That doesn't matter.  It is not in /, so it is not available for early
userspace.  Therefore, it doesn't meet the requirements.

> /lib/ doesn't fit either IMO,... /boot sounds perhaps ok?!

No. /boot can (and often is) a separate partition.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh