bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FHS (Re: translator for /dev/random and /dev/urandom)


From: Joshua Rosen
Subject: FHS (Re: translator for /dev/random and /dev/urandom)
Date: Sun, 24 Jun 2001 13:56:04 -0400

Marcus Brinkmann wrote:
> 
> On Sat, Jun 23, 2001 at 06:47:12PM +0200, Oystein Viggen wrote:
> > Quoth Marcus Brinkmann:
> >
> > >   Use --seed-file to store a seed file across reboots (in /var/run).
> >
> > At least in Debian GNU hurd, the boot scripts seem to do this:
> >
> > if test -d /var/run; then
> >   (cd /var/run && { rm -rf -- *; cp /dev/null utmp; chmod 644 utmp; })
> > fi
> 
> This is a bug and will be fixed in the next version.
> 
> > Wouldn't this make /var/run an exceptionally bad place for storing stuff
> > across reboots?
> 
> The next version will excempt random-seed (and directories, and innd.pid and
> utmp).  I should add an excemption for urandom-seed, too.

Do we (should we) pay attention to the Filesystem Hierarchy Standard?

Of /var/run, the FHS says:

       5.13.1  Purpose

       This directory contains system information data describing the
system
       since it was booted.  Files under this directory must be cleared
       (removed or truncated as appropriate) at the beginning of the
boot
       process.

(also stated is that utmp should be kept in /var/run, implying that it
should *not* be reserved across reboots...)

It seems that /var/lib is a much more suitable place for storing seeds,
as the associated text is:
       5.8  /var/lib : Variable state information

       5.8.1  Purpose

       This hierarchy holds state information pertaining to an
application or
       the system.  State information is data that programs modify while
they
       run, and that pertains to one specific host.  Users must never
need to
       modify files in /var/lib to configure a package's operation.

       State information is generally used to preserve the condition of
an
       application (or a group of inter-related applications) between
       invocations and between different instances of the same
application.
       State information should generally remain valid after a reboot,
should
       not be logging output, and should not be spooled data.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]