Lennart Poettering wrote:
Footnotes:
[1] And I certainly don't want other people using my machine to spy on
my VoIP calls or listen into the audio track of my very private
porn videos! ;-)
But sometimes you do want simultaneous multiplexed access or random use
among a set of users/processes not separated by any particular event.
It should be the administrator/users decision about who can do what, not
hard coded in a program. Controlling access among multiple users on a
multi user operating system isn't exactly a new concept except for the
recent notion that logging in at the console (if you happen to have such
a thing) should magically give you ownship of more than /dev/tty. Why
can't you provide an init.d script to be used (optionally) to start a
daemon associated with a local sound device if you need it to handle
processes not associated with a login (perhaps mythtv or any of the
jukebox server process), add a group that will always be permitted
access so certain users/processes can be given permanent access
regardless of any events, and use kernel locking if you want to
guarantee exclusive access? That makes it the usual 'service
service_name start/stop' and 'chkconfig service_name on' operations that
fedora/RH users expect to use to control optional daemons. If sessions
that proxy to remote devices run separate daemons, those could still be
started on demand, and if you don't need the init.d daemon, you wouldn't
have to use it.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
