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