From: Kurt Konolige <konolige@AI.SRI.COM>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplug, 1394, and security
Date: Sun, 27 Nov 2005 05:45:28 +0000 [thread overview]
Message-ID: <438947F8.3030204@ai.sri.com> (raw)
In-Reply-To: <20051125213209.GZ20781@conscoop.ottawa.on.ca>
The 1394 Trade Association puts out something called the "IIDC
1394-based Camera Specification", which most folks just call the DCAM
spec. You control the camera by reading and writing into its 1394
address space, which is structured according to this spec. I think IEC
61883 defines a wrapper structure of iso packets that hold video;
devices with uncompressed video typically don't use it.
At any rate, user space control over the camera hinges on writing to
/dev/raw1394, to set camera parameters. I frequently have to change the
default /dev/raw1394 access controls on new Linux systems, to enable
DCAM controls. It would be a pain if this were restricted to root access.
Cheers --Kurt
Jody McIntyre wrote:
> On Sat, Nov 26, 2005 at 08:07:58AM +0100, Stefan Richter wrote:
>
>>Kurt Konolige wrote:
>>
>>>Will libraw1394 access be
>>>restricted to root, as a default policy? There are user programs that
>>>need access to libraw read/write, at least for DCAM-compliant devices.
>>
>>In my opinion, the kernel should not enforce one or the other policy. As
>>long as a policy (e.g. security policy) can be controlled in userspace,
>>control it in userspace.
>
>
> I agree. It's really up to your udev configuration. You could even
> continue to give your video users full /dev/raw1394 access (but you
> wouldn't have to.)
>
> What do you mean by "DCAM-compliant"? IEC 61883?
>
> Cheers,
> Jody
>
>
>>--
>>Stefan Richter
>>-===-=-=-= =-= =-=-
>>http://arcgraph.de/sr/
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2005-11-27 5:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-25 21:32 Hotplug, 1394, and security Jody McIntyre
2005-11-25 21:49 ` Kurt Konolige
2005-11-25 22:52 ` Jody McIntyre
2005-11-25 23:29 ` Stefan Richter
2005-11-26 6:52 ` Kurt Konolige
2005-11-26 7:07 ` Stefan Richter
2005-11-27 5:03 ` Jody McIntyre
2005-11-27 5:28 ` Jody McIntyre
2005-11-27 5:45 ` Kurt Konolige [this message]
2005-11-27 13:39 ` Stefan Richter
2005-11-27 13:50 ` Stefan Richter
2005-11-27 13:55 ` Stefan Richter
2005-11-28 22:30 ` Jody McIntyre
2005-11-29 0:08 ` Stefan Richter
2005-11-29 5:43 ` Jody McIntyre
2005-11-29 7:57 ` Stefan Richter
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=438947F8.3030204@ai.sri.com \
--to=konolige@ai.sri.com \
--cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).