how is pulseaudio supposed to work?
Les Mikesell
lesmikesell at gmail.com
Wed Dec 19 20:05:08 UTC 2007
Lennart Poettering wrote:
>>> I think one of the problems here is CK runs against a body of shared
>>> administration experience
>>> in the community. There isn't a shared understanding of how to use CK
>>> effectively to get common hardware related admin crap done, so as a
>>> result any explanation on how to do something semi-involved as an
>>> administrator which boils down to "it uses CK to do it" just doesn't
>>> connect.
>> Yes, that doesn't make any sense to me - even the concept of 'active
>> session'. If your X display is on a nearby machine (or several) but you
>> want local audio, is that 'active' or not in PA speak? What if you have
>> mythtv running but not related to a logged in session and also want to log
>> in?
>
> You're always welcome to change he default configuration of CK.
>
> The point of CK is that we try to fix a gaping security hole: think of
> a university system: a workstation where different people logon/logoff
> all the time. Right now, a user may keep open the sound card forever,
> and use it to spy people who access the same machine later
> on. I.e. use the mike to listen to what they are saying and stuff like
> that.
I thought kernel locks were the appropriate mechanism to ensure
exclusive access and files/devices should all be abstracted to look the
same.
> If you don't care about that kind of security than you are always
> welcome to change the configuration. But I believe that the default
> installation of Fedora should be reasonably secure, and that this
> should be a priority.
I just don't see the conceptual difference between this device and
(say) a tape device. It seems as silly to give exclusive access to a
sound device based on an assumed proximity as it would with a tape
device that is likely to also be needed for scheduled jobs - and will
need exclusive access. And even stranger to tie access to some
particular window manager startup when many different ones may be
running along with processes not running under X and ones tunneled via
ssh instead of having a local session.
--
Les Mikesell
lesmikesell at gmail.com
More information about the fedora-devel-list
mailing list