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
_______________________________________________
networking-discuss mailing list
[email protected]
