Interesting proposal. Of the bikeshed options, I like the ones with
"credential" in them over those mentioning "session" or "process
group" (since there are no process collectives that allow pre-existing
processes to join them).
Some questions:
1. What are the default registered CPG types on a newly booted
system? (Are there CPG types created by the kernel prior to the
creation of init(1M)?)
1'. If the kernel does create such types, how do they participate in
the "resource release at empty" operation?
2. Why 64-bit IDs, and not reuse of id_t and idtype_t? (Unusual for
a process collective.)
3. What is the complete list of system calls that cause a CPG to
change its settings? For instance, should setuid(2) or
setppriv(2) calls also have CPG_F_* flags?
4. There's no new privilege needed for CPG type registration or
removal? What privilege is required?
5. Do you expect the behaviour of a cpg_type_unreg() call to be
blocking--destroying all CPGs of that type--or merely allow those
CPGs to linger until all processes have exited. What happens to
CPGs with door calls in the _unreg() case?
6. It would be helpful to see the Boomer example explained a bit, if
any preliminary sketch is available. (My feeling is that there's
a lot of public mechanism for one consumer.)
7. Usually the zone/project/task/process resource controls need to be
transferred in the attributes of the work unit of whatever
subsystem is taking the request out of process context but, if
you've worked out more about subsuming those attributes, I'd be
interested in seeing the details.
8. Could the project team comment when they expect a new feature
should introduce a CPG type, rather than a process privilege? It
might also be useful to understand how CPGs might be used to
implement a concept like a security label, as in classic Trusted
Solaris? I suppose I'm looking for early advice about how to
design using this feature. (For instance, if the answer to 1/1'
is "no", then does that imply kernel features must introduce
privileges?)
Thanks
Stephen
--
sch at sun.com http://blogs.sun.com/sch/
