Darren Reed wrote: > I'd like a person or two to have a look over the proposed patch (URL to > webrev) and review the proposed fix: > http://cr.opensolaris.org/~darrenr/6271923/ > > To quote myself from the CR: > > "The proposed fix (at this stage) is: > * to create a new project (inetd) that has its maximum number of > contracts set > to 1,000,000,000 because /etc/project cannot be used to remove a > resource control > for a project, only set them. > * to have inetd run under the "inetd" project by modifying the inetd > manifest > such that it now includes a method_context and method_credential.
ok > * to modify inetd itself to put all of the children it forks off back > into the > "default" project - if their SMF profile specifies a new project, that > will > be applied later. Would you expand the comment on 2697 in inetd.c to clarify that the service's project definition will be set later in the function. Did I miss your rationale for choosing 'default' project rather than 'system', which is the current inheriting project? > > The rationale for putting inetd in its own project rather than having it > modify > or remove a resource is to place the configuration such that the system > administrator can easily access it, without needing to create new controls. > Agreed. It's simpler to modify existing settings. > There are two dangers with this fix: > - sites that have already put inetd into a different project may get > surprised > if/when they do an "upgrade" or "patch". > - sites that already have defined an inetd project will also experience > problems. > > My expectation is that both of these catches are likely to be very > uncommon, if > not down right rare or non-existant and when weighing up the risks vs the > benefits, the benefits would clearly seem to win." > Agreed. -tony
