PSARC 2009/271 Credential Process Groups (CPGS)

[Garrett D'Amore]

Stephen Hahn wrote:
>
>   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.)
>   

Boomer 's use of this will be for Sun Ray audio.  For Sun Ray audio, we 
need to know -- in the context of a file opened against "/dev/mixer" or 
"/dev/dsp", what the Sun Ray session is.  At the moment, we think any 
reasonably unique value (unique on the host at the time of creation) is 
sufficient.  This allows us to work around the fact that OSS 
applications don't have a standard "AUDIODEV" environment variable that 
can be overridden.  It also allows us to avoid creating "scratch" device 
nodes in the /tmp file system.

The pattern would be something like this:

* pam_sunray (or somesuch) creates a CPG for the Sun Ray session on 
authentication

* open("/dev/dsp") or open("/dev/audio") retrieves the CPG, and notices 
that the session is associated with a Sun Ray session, and sets up some 
in kernel mapping between the CPG and a userland process that routes 
audio to the actual device.  This state would probably be tracked on a 
cloned minor node allocated dynamically at open() time.  (Standard 
Solaris cloning semantics.)

* All future ops on the cloned minor now are referenced against the 
specific Sun Ray session logical device

* At close() time we can tear down the mapping (possibly using some kind 
of reference counting)

* At logout, the pam module would free the CPG state, and toss any stale 
mappings.

I don't know if that is clear enough, but I hope it conveys the general 
idea.

    - Garrett