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.
Nico
--
