Keith M Wesolowski wrote: > > More generally, now. I can certainly file a bug on the above (it's > really another variation on 6598922) but there are other possible > failure modes here, and it's very hard to be sure we've gotten all of > them. For example, suppose an NSS database backend (or NSS itself) > were to store pieces of its configuration in the SMF repository. When > it goes to look up those values to service a lookup, it would be > vulnerable to the same type of deadlock. > > Duckwater folks: Are you aware of this? How do you intend to solve > (or avoid) it?
Yes, we're ware of this and we will pay even more attention to it as one of Duckwater's goal is to move most of name services configuration to SMF. Easy way (IMO) to avoid this kind of problems would be to keep code in name service components interacting with svc.configd off of lookup code paths - I believe we can do it in most if not all cases. It wasn't the case with nscd and "6628289 svc.configd hangs in deadly embrace with nscd". It's still not (after fix to 6628289 was put back), but special care is now being taken to avoid the possible lock up in nscd. Also, the very least we can start with to have the situation under control is making sure we ask each other (Netrep and SMF teams) for code-reviews. Duckwater team definitely plans to do so once we get closer to project completion. > > SMF folks: is there hope of establishing (and verifying compliance > with) a set of locking rules that can definitely prevent these > conditions? Is it worth doing, or is some alternate set of > restrictions more appropriate (perhaps banning the name service > components from calling into configd)? > I believe banning the name service components from calling into configd would be very unfortunate, but we can certainly limit the access from NS to svc.configd to places, where it's safe and identify the parts of code, where there's potential threat and make sure we behave correctly (as in fix for 6628289). Tomas
