David Bustos writes:
> [ blind carbon-copied to security-discuss, nwam-discuss, and
> sparks-discuss ]
>
> The second draft of the Enhanced SMF Profiles design is now available at
> http://opensolaris.org/os/project/smf-profiles/Design , along with a PDF
> at http://opensolaris.org/os/project/smf-profiles/Design/design.pdf .
> The revision adds an explanation of how SCF works today, introduces
> a new precedence scheme, and introduces "conditional configuration". It
> still only proposes the model, however; details of the interfaces are
> the next step. As this is a major rewrite, fine-grained differences
> from the last version won't be provided. If you are so inclined, please
> review it and send feedback to smf-discuss.
>
>
> Thanks,
> David Bustos
> Susan Kamm-Worrell
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
This document covers a lot of ground, so I wish that I had the time to read
it twice. For now, however, here are my comments based on one reading.
Immutability - 1st two sentences
"The proposed upgrade procedure calls for upgrading
developer-delivered profiles by replacement. For administrators who
place customizations in such a profile, this will result in a truly
lousy experience."
Why would administrator customizations go in the
developer-delivered profile? Shouldn't they go in the local
profile? Perhaps, you are saying that making a profile immutable
is the way to enforce this behavior.
Conditional Configuration
- How are conditions defined?
- How does SMF (startd?) know when conditions change?
- Really don't like the idea of hard coding conditions into
svc.configd. Developers in non-ON consolidations would have a
hard time creating conditions.
Conditional Profile Order:
- This section is difficult to understand. Some examples would be
helpful. Also perhaps a little more detail on "will provide a
mechanism for condition developers to declare mutual exclusivity"
and why it would be useful.
Secure by Default:
- I agree that the netservices command should remain. It is so
easy to use and hides all the complexity of making the
transition. It appears to me that manipulating profiles is going
to be so difficult to comprehend that it should only be done with
tools that hide the profile complexity.
Profiles:
libscf Interface:
- An example of "negative entry" would be helpful to me.
Alternatively, perhaps you can show one on the diagram. Also,
how does the administrator create negative entries.
Administrative Features:
- It may be handy if the "profile list" and "property in profiles"
commands would contain an option to tell which authorizations are
necessary to make changes. I say this, because the administrator
can no longer just look at the manifest to make that
determination.
- Other tools that might be handy:
o list condition values
o tool to help determine which predicates are being
evaluated in the decision to activate a given profile.
Since profiles, precedences and inclusions all have
predicates, the picture can get complicated
o Is punch-through active?
Service implementation:
- "Services which disable themselves when they determine they
shouldn't run should instead employ conditional configuration."
The conditions for whether or not a service should run may be
more complex than can be represented by conditions and
predicates. This is especially true if the conditions are hard
coded in configd.
General comments:
Once all the levels have been introduced, it would be good to have
a level summary. For each level it would be handy to have the
following information in the summary:
- How does it get populated?
- Can it be modified? If so, how?
- Is it conditional?
- Is it modifiable by admin? Via svc* commands or
indirectly via a special tool?
- any other special characteristics,
e.g. punch-throughable, immutable, etc.
Can new levels be created on the fly? From my reading of the wpad
use case, it looks as if they can.
