On Dec 24, 2013, at 2:53 PM, Xin Li <delp...@delphij.net> wrote:

> Hash: SHA512
> On 12/24/13 14:36, Paul Hoffman wrote:
>> On Dec 24, 2013, at 12:44 PM, Xin Li <delp...@delphij.net> wrote:
>>> I think we shouldn't save entropy inside jails, as the data is
>>> not going to be used by rc script (pjd@126744).  If there is no 
>>> objections, I will commit this changeset on January 1, 2014.
>> Even if it is not used by an rc script, it might be used by some 
>> userland program (running as root, of course) that knows about the 
>> directory and wants some fresh entropy for its own use.
> Why a userland application would want to use these?  Would you mind
> elaborating what kind of use that would be?

I don't have a specific application in mind, and certainly not one for a jail. 
However, I'm not sure what the value in removing a feature for a jail if we 
don't know if anyone is using that feature. Thus, my question.

> My understanding is that the saved entropy is used for bootstraping
> the system only: any applications that wants good random numbers
> should just use /dev/random because relying on something saved on disk
> is the worst way for someone who wants more entropy.

Quite true. Note, however, that we don't delete the saved entropy after booting 
and add it just before shutdown: we leave it there for some reason. I'm not 
sure why a jail is so different of an environment that it should be treated 
differently than a normal (non-jail) environment. Maybe there is a reason, but 
I'm not seeing it.

>> Is there a problem with saving the directory in jails? It
>> certainly isn't taking up much space.
> No, it's not about space.  What I am concerned is that it may have
> wasted entropy: each time (every */11 minute) the system would get
> 2048 bytes out from /dev/random per jail.  This deterministic behavior
> may trigger reseeds earlier than wanted.

I did not understand this. What changes in the system does removing 
/var/db/entropy cause? (If this is answered in a longer article, a pointer to 
it would be useful to me (and maybe others).)

--Paul Hoffman
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to