[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-sparks-discuss
Subject:    Re: [sparks-discuss] [smf-discuss] SMF v. NSS: deadlock central
From:       Nicolas Williams <Nicolas.Williams () sun ! com>
Date:       2007-11-20 17:41:43
Message-ID: 20071120174143.GI26622 () Sun ! COM
[Download RAW message or body]

On Tue, Nov 20, 2007 at 09:59:37AM -0700, Tom Whitten wrote:
> I think a review of the configd locking rules is definitely in order.  As
> you point out, it is not just a matter of holding the locks.  We also need

A rule like "don't sleep or do long running calls while holding locks"
(e.g., name services calls), would be good (that was essentially my
suggestion).

> to understand when the rn_flags are being set and how they can create a
> deadlock.  perm_granted() is only called in 6 places, so I think that we
> should be able to come up with a solution that we are confident in.
> 
> Nico's suggestion is intriguing.  I'd like to include it in the study.

I missed something.  My suggestion _alone_ would trade a deadlock for an
infinite loop.

A complete fix based on my original suggestion would also require that
calls to svc.configd from name services daemons be authorized without
requiring RBAC getXbyYs.  (E.g., get the caller's process contract ID,
map that to an FMRI, assign authorizations to FMRIs, and do authz that
way; alternatively, add new privileges.)

My suggestion, modified as above, has the great benefit that there'd be
no need to modify nscd, nss backends, and other such system components.
Only svc.configd would need modification (and perhaps some manifests,
depending on how we decide to authorize daemons' access to SMF).

Nico
-- 
_______________________________________________
sparks-discuss mailing list
sparks-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sparks-discuss
[prev in list] [next in list] [prev in thread] [next in thread]