Ideas on NSS vs fork?

Ideas on NSS vs fork?

[Tommi Virtanen]

NSS, the crypto library Red Hat likes to use, cannot tolerate
forks. NSS_NoDB_Init must be called after daemonization, and there
seems to be no way around it; for example, calling it again is
explicitly forbidden.

The code in branch wip-nss-vs-fork adds a common_init_daemonized
function, that things that (potentially) daemonize must call, after
the point where they'd daemonize. Non-daemons are handled in
common_preinit and need nothing special.

Users of libceph/librados cannot fork, and expect to keep using the
library :(

The "remove this" comment on libceph_initialized cannot be blindly
acted on; similar logic could be pushed down into ceph::crypto::init,
though.

This is ugly, but it's the best I could do. Please go through the code
and let me know if you have any ideas on how to make it less painful.

In the meanwhile, if you need NSS to work, you can always run in
non-daemonizing mode, with -f.


P.S. Please use Crypto++. For my sanity.

-- 
:(){ :|:&};:

Re: Ideas on NSS vs fork?

[Colin Patrick McCabe]

On Thu, Apr 28, 2011 at 2:29 PM, Tommi Virtanen
<tommi.virtanen@dreamhost.com> wrote:
> NSS, the crypto library Red Hat likes to use, cannot tolerate
> forks. NSS_NoDB_Init must be called after daemonization, and there
> seems to be no way around it; for example, calling it again is
> explicitly forbidden.
>
> The code in branch wip-nss-vs-fork adds a common_init_daemonized
> function, that things that (potentially) daemonize must call, after
> the point where they'd daemonize. Non-daemons are handled in
> common_preinit and need nothing special.
>
> Users of libceph/librados cannot fork, and expect to keep using the
> library :(

We already are in a situation where the child process after a fork
can't use librados or libceph. The reason is because the child process
will not have any threads besides the main one.

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.

>
> The "remove this" comment on libceph_initialized cannot be blindly
> acted on; similar logic could be pushed down into ceph::crypto::init,
> though.
>
> This is ugly, but it's the best I could do. Please go through the code
> and let me know if you have any ideas on how to make it less painful.

Daemonization should be done in common_init. Obviously, only daemons will do it!

Daemonization has nothing to do with the messenger logically, so it
will be good to get that stuff out of there.

Colin.

>
> In the meanwhile, if you need NSS to work, you can always run in
> non-daemonizing mode, with -f.
>
>
> P.S. Please use Crypto++. For my sanity.
>
> --
> :(){ :|:&};:
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ideas on NSS vs fork?

[Sage Weil]

On Thu, 28 Apr 2011, Colin Patrick McCabe wrote:
> > The "remove this" comment on libceph_initialized cannot be blindly
> > acted on; similar logic could be pushed down into ceph::crypto::init,
> > though.
> >
> > This is ugly, but it's the best I could do. Please go through the code
> > and let me know if you have any ideas on how to make it less painful.
> 
> Daemonization should be done in common_init. Obviously, only daemons 
> will do it!

Well, probably after that.  There is a lot of initialization that 
intentionally runs before daemonization (so that you get feedback on 
errors, etc.).

> Daemonization has nothing to do with the messenger logically, so it
> will be good to get that stuff out of there.

Yeah.  SimpleMessenger::start() basically does some checks, forks, and 
then starts a thread.  The forking bit can be moved out, and I think most 
of the checks are obsolete anyway.

sage

Re: Ideas on NSS vs fork?

[Tommi Virtanen]

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.)

-- 
:(){ :|:&};:

Re: Ideas on NSS vs fork?

[Tommi Virtanen]

On Fri, Apr 29, 2011 at 09:14:24AM -0700, Tommi Virtanen wrote:
> (The Ceph daemons before commit c9825f08 follow #1, that commits makes
> them follow #2.)

I mean 6eb7e1c0dc6ca6df7e59f813f392a50c728b474e, in branch
wip-nss-vs-fork currently.

-- 
:(){ :|:&};: