PSARC 2009/271 Credential Process Groups (CPGS)

[Stephen Hahn]

  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/