From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Some fixes for alsa_stream
Date: Wed, 15 Jun 2011 11:51:52 -0300 [thread overview]
Message-ID: <4DF8C708.1050009@redhat.com> (raw)
In-Reply-To: <4DF8C32A.7090004@redhat.com>
Em 15-06-2011 11:35, Hans de Goede escreveu:
> Hi,
>
> On 06/15/2011 04:25 PM, Mauro Carvalho Chehab wrote:
>> Em 15-06-2011 10:43, Hans de Goede escreveu:
>
> <snip>
>
>>> Right, because ConsoleKit ensures that devices like floppydrives, cdroms, audio cards,
>>> webcams, etc. are only available to users sitting behind the console,
>>
>> This is a wrong assumption. There's no good reason why other users can't access those
>> devices.
>
> This is not an assumption, this is a policy decision. The policy is that devices like
> audiocards and webcams should be only available to local console users / processes. To
> avoid for example someone from spying upon someone else sitting behind the computer.
>
> <snip>
The concept behind the policy decision is right, but the policy itself and its
implementation are wrong.
It makes sense to protect the access to the notebook/desktop microphone and webcam to
the console, but it doesn't make sense to assume that all audio cards and video devices
are microphones and webcams. There are several cases where they aren't, like mythtv/vdr
servers, Video Surveillance devices, TV boards, etc.
Also, I know at least one usecase where a Radio broadcast station is using an USB
webcam to allow their audience to see what's happening there. So, even the assumption
that all webcams need protection is wrong (In this specific case, they really want
to allow someone else to spy what's happening there ;) ).
That's said, it is OK that the default will be to not allow accessing to them, but
adding someone else to the audio/video group should be enough to allow users to
override this protection.
Mauro.
next prev parent reply other threads:[~2011-06-15 14:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 2:01 Some fixes for alsa_stream Mauro Carvalho Chehab
2011-06-14 12:48 ` Hans de Goede
2011-06-14 13:05 ` Mauro Carvalho Chehab
2011-06-14 13:39 ` Mauro Carvalho Chehab
2011-06-14 13:47 ` Hans de Goede
2011-06-14 13:52 ` Devin Heitmueller
2011-06-14 14:17 ` Mauro Carvalho Chehab
2011-06-14 14:37 ` Hans de Goede
2011-06-14 14:45 ` Mauro Carvalho Chehab
2011-06-14 14:48 ` Devin Heitmueller
2011-06-14 15:51 ` Mauro Carvalho Chehab
2011-06-15 13:43 ` Hans de Goede
2011-06-15 14:25 ` Mauro Carvalho Chehab
2011-06-15 14:35 ` Hans de Goede
2011-06-15 14:51 ` Mauro Carvalho Chehab [this message]
2011-06-15 15:45 ` Mauro Carvalho Chehab
2011-06-16 12:29 ` Hans de Goede
2011-06-16 14:38 ` Mauro Carvalho Chehab
2011-06-16 15:11 ` Hans de Goede
2011-06-16 15:35 ` Mauro Carvalho Chehab
2011-06-16 18:19 ` Hans de Goede
2011-06-16 18:28 ` Mauro Carvalho Chehab
2011-06-15 14:36 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DF8C708.1050009@redhat.com \
--to=mchehab@redhat.com \
--cc=dheitmueller@kernellabs.com \
--cc=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox