On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote: > On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote: > > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > > > On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev > > > wrote: > > > > I understand the concern. The issue I am wrestling with is > > > > strict > > > > compatibility with the existing code. Does anyone really *want* > > > > the > > > > RNG’s to not reseed on fork? It’s hard to imagine, but maybe > > > > somewhere someone is. And then it’s not about just reseeding, > > > > but > > > > what about when (if) we add other things, like whether or not the > > > > secure arena gets zero’d in a child? > > > > > > > > So let me phrase it this way: does anyone object to changing the > > > > default so NO_ATFORK must be used to avoid the reseeding and > > > > other > > > > things we might add later? > > > > > > I can hardly see anyone would be broken if the default is to reseed > > > RNG on fork. However that might not be true for other atfork > > > functionalities so perhaps there is a need to make each of these > > > future > > > atfork functions configurable and either on or off by default > > > individually and not as a whole. > > > > There might be cases where after fork you're not able to get to > > /dev/urandom anymore. > > I do not think so. Which particular cases do you have on mind? Yes, > after fork+exec you could for example switch SELinux domain and won't > be able to access something but immediately after fork it should not be > so. Also perhaps the reseeding after fork can be made less strict in > regards to failures reading /dev/urandom or so.
It seems to me this all depends on the order of things you do to create a daemon. You could make sure the RNG is inited, chroot, and then fork for instance. And I suspect there are actually programs that do it in that order. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
