Nicolas Williams wrote:
> On Mon, Dec 15, 2008 at 10:21:17PM +0100, Casper.Dik at Sun.COM wrote:
>
>> As long as we don't have a "session" which can be nicely grouped, it
>> makes sense to make all $AUDIODEVs virtual, but they should not be all
>> called /dev/audio. If we want to virtualize /dev/audio (the device
>> itself), then I would like to see some mechanism which allows a
>> device to distinguish between different "sessions".
>>
>
> Solaris has lots of process groupings: SysV process groups, BSD/SysV4
> session IDs (which are not really sessions), task IDs, audit session
> IDs, ...
>
> AFS has had a concept called PAG ("process authentication groups") which
> is a session ID that once set stays set until explicitly changed (i.e.,
> survives across fork(), exec() (including of set-id programs), setuid()
> and friends) and which can only be set only to unique IDs or to PAGs
> that the user already owns.
>
> OpenAFS emulates PAGs on Solaris by encoding PAGs in two group IDs in
> the supplementary group list. This gets it the desired inheritance
> semantics (unless you setgroups() or initgroups()).
>
> AFS uses PAGs to associate client processes with Kerberos credentials.
> We want/need equivalent functionality in Solaris for secure NFS.
>
> This case makes it clear that we need something like controlling tty, or
> PAGs but for audio. Controlling ttys is probably not a good model for
> audio in that it'd make it to difficult to switch a process' controlling
> audio devices. PAGs seem to have better semantics for audio.
>
> We have a variety of process grouping semantics:
>
> - process groups and session IDs: group membership associated with
> ttys, existing apps may change these at any time, therefore one
> cannot build other kinds of sessions on top
>
> - audit session ID: not changeable once set, requires privilege, not
> available unless auditing is enabled (this will change, eventually)
>
> - task IDs: associated with resource controls, existing apps may change
> these at any time; not suitable for building other kinds of sessions
> on top
>
> - process contract membership: settable only for children, not
> changeable
>
> Generally all process grouping schemes will be unsuitable for layering
> multiple unrelated applications on top of them. But it seems that most
> of the time we'll want PAG-like inherittance semantics, which makes
> cred_t a good light-weight vehicle for representing membership in such
> groups, and for something like the NFS/CIFS clients (and OpenAFS), quite
> appropriate. On this theory my view is that a typed data array in
> cred_t plus syscall and ucred extensions to deal with it is worth
> exploring.
>
You've nailed the problem down pretty well. I'm familiar with AFS PAGs,
and I always thought they were a bit strange (reusing supplementary
group ids).
I'll see if I can come up with a draft case describing this later this
week, or possibly next.
-- Garrett
> Nico
>
