PSARC 2009/271 Credential Process Groups (CPGS)

[Edward Pilatowicz]

hey nicolas,

so i started reviewing these materials from a zones integration
perspective, but while reading them i realized that i had a lot of
general questions as well wrt how this functionality would actually
work.  i've attached my questions, broken into two sections.  first
is the general questions (to help me understand this stuff better)
and second is the zones related questions.

thanks
ed

On Thu, Apr 30, 2009 at 02:58:32PM -0500, Nicolas Williams wrote:
> On Wed, Apr 29, 2009 at 08:59:08AM -0700, Garrett D'Amore wrote:
> > The inception materials are now available:
>
> I've added two files to inception.materials/man:
>
>  - cpg.1
>
>    A manpage for a new command.
>
>
>  - pcred-diffs
>
>    Diffs to pcred(1).
>
> The Overview.txt file refers to pcred changes but not to cpg(1); I'll
> leave it as is.  Similarly, I'll leave the 20q.txt file as is.
>
> Nico
> --
-------------- next part --------------
-------------------------------------------------------------------------------
general questions:

- you repeatedly state that CPGs are associated with login sessions.
  please define a login session in the CPG context and provide examples.

  you also mention that CPGs will help with obtaining credentials for cron
  jobs, which specifically don't have a login session (as i understand
  login sessions), so please explain how this works.


- you mention that CPGs are bound to credentials (there seems to be a
  1:1 mapping), but in my gdm login session, different xterms have
  different cred_t pointers.  so will different xterms have different
  CPGs?  (once again, perhaps this confusion results from my lack of
  understanding of how "login sessions" are defined wrt CPGs.)


- group membership is represented in cred_t.  does this impact cred_t
  comparisons?  (ala crcmp()).


- why must CPGs IDs be unique (since boot)?


- why isn't ps(1) being modified to display the CPGs ID?


- is the CPG door upcall mechanism used for anything other than a
  notification for when a CPG group becomes empty?  (i'm worried that
  perhaps we're adopting the linux behaviour of having the kernel spawn
  processes to prompt the user for information.)


- given that CPGs are associated with credentials, how could they
  replace process project(4)s and tasks, which can contain process
  with different credentials?


- you mention encoding ssh agent information in CPGs.  afaik, the
  current problem with ssh agent environment variables is that if
  someone connects to a machine via ssh, starts the ssh agent, then logs
  into the machine again via ssh, the second login session won't know
  about the agent started by the first session.  how can CPGs solve this
  problem?


- you mention that on linux, a process may manipulate it's parents PAGs.
  will this be possible for solaris?  (i'm hoping the answer is no.)

  if it's yes, could you please site me some examples of subsystems
  where a subprocess is allowed to modify it's parents properties?
  (i can think of examples where one process can modify another via
  /proc or some -p type option, but these are all subject to priv
  checks and not just blindly permitted because there is some kind of
  causal relationship between the two processes.)


- cpg_chown() and cpg_chown_byid()

  please define a CPG owner.  (do CPGs have an owner that is separate
  from the cred_t associated with the CPG?)

  when would you ever want to change the ownership of a CPG?

  what happens to all the processes bound to that CPG when it's
  ownership changes?


- it seems like there are a lot of CPG data modifier flags.  are
  CPG_S_SESSION_PRIVATE_DATA and CPG_S_SENSITIVE_DATA really useful?
  they require proc_session and proc_info respectively, and both
  these privs are included in the basic set, so who are you actually
  protecting this "private/sensitive" data from?


- a 64-byte user data field for a CPG seems small.  how did you decide
  on this size?  is there any reason the size isn't specified when the
  CPG type is created?


- why bother with _CONFIG_NCPGROUPS?  (it seems like it would be more
  usefull to have a sysconf variable for the size of the user data if
  you plan to keep it as a fixed size.  using sysconf for this instead of
  a define would allow for easier increases of the value in the future.)


-------------------------------------------------------------------------------
zones questions:

- this worries me:
	- New CPG types can be registered early at boot time in the global
	  zone

  why isn't the CPG type namespace unique across zones and why can't
  zones create their own CPG types?

  why can CPGs only be created early in boot?  please define early.

  the cpg(1) command seems to be able to create and destroy cpg types.
  will this command fail if it's run after the system is booted?

  if CPG types can be created after boot, are there any resource limits
  on CPG type creation?  are there any privs to control CPG type
  creation?


- if CPGs are used by things like kerberos, and kerberos is not enabled
  in the global zone, but it is enabled for a non-global, how will the
  kerberos CPG type be registered?  (this also applies to other services
  that may use CPGs in the future, like ssh, etc.)


- this also worries me:
	CPG types will be registered in the global zone by an SMF service
	per-CPG type.  These services will also be able to register a door (in
	the global zone and in non-global zones) that will receive upcalls
	indicating CPG emptiness events.

  so global zone services are registering doors within zones?  doors are
  bound to paths.  so how do these services deal with zones that are not
  mounted, attached, installed?  what happens when zones are destroyed?
  are these services monitoring zone state changes?


- what happens to CPG associations during a zlogin (and other
  zone_enter() consumers).


-------------------------------------------------------------------------------