17 Nov
2003
17 Nov
'03
12:16 a.m.
Jack O'Quin writes:
> One of the things I like about the `audio'
group approach is that
> it is easy to administer and simple to verify who has access to
> those privileges.
martin rumori <ptiger(a)gmx.de> writes:
i think, that's a clean solution. to be able to
distinguish between
realtime- and non-realtime-audio users, i'd propose to use a separate
group (e.g. 'rtaudio'), so
(5) introduce a group 'rtaudio', whose members are granted realtime
privileges.
on a multiuser system, i think it's not necessary to grant realtime
privileges to every user who wants to hear his custom system beeps :-)
That's right. Separating the `realtime' from the `audio' seems
logical to me. Not all audio is realtime, and not all realtime is
necessarily audio. Video or other applications could also benefit
from this mechanism. Maybe we should just invent a group named
`realtime'.
Note that the group name issue is separate from the underlying kernel
mechanism. In Debian, group `audio' has gid 29. One should not hard-
code that in the kernel. I would envision a user-level admin process
that accesses the appropriate group name and writes its numeric gid
value with sysctl. The kernel security module would use whatever gid
value it is given.
--
joq