On Thu, Apr 28, 2011 at 11:02:57PM -0700, Colin Patrick McCabe wrote:
> The question we need to answer is really whether forking somehow
> destroys the state of the parent process, even if the child thread
> never runs any libNSS code. If the answer is no, which is very likely,
> then essentially our situation is unchanged.
For NSS, only the pid that ran ceph::crypto::init() has a working
crypto library.
1. If you init before forking, any forked processes will have their
NSS return errors, with no way to fix that. The parent keeps
working.
2. If you init after forking, the parent never even tries to init crypto,
the child does and gets a perfectly working crypto library.
2b. As an extension of above, the parent *could* init crypto after it
has already forked off the child. We just have no need for that.
None of these make it possible for the child to wreck the NSS state in
the parent.
(The Ceph daemons before commit c9825f08 follow #1, that commits makes
them follow #2.)
--
:(){ :|:&};:
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
