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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
