** Description changed:
- Deleted my post, it was incorrect.
+ Reopening this bug.
+
+ In Ubuntu 8.10 (Alpha 6) importing dv over firewire does not just work
+ with Kino 1.3.0
+
+ I'm back at the familiar message: WARNING: raw1394 kernel module not
+ loaded or failure to read/write /dev/raw1394
Kino has not supported video1394 for years. You are meaning dv1394 when
you write video1394. Also, why do you think I did not enable that
option by default? The answer is that it imposes major usability issues.
The new firewire subsystem and libraw1394 2.0 have resolved the security
issue with
Duncan Lithgow wrote:
Reopening this bug.
In Ubuntu 8.10 (Alpha 6) importing dv over firewire does not just work with
Kino 1.3.0
I'm back at the familiar message: WARNING: raw1394 kernel module not loaded
or failure to read/write /dev/raw1394
My first guess is that this is because
Capturing DV video over the desktop should be straightforward, just like
downloading pictures from a camera. This is directly related to bug #1, the
Firewire port should be used by applications just like USB port.
--
use /dev/video1394, not /dev/raw1394
https://bugs.launchpad.net/bugs/6290
Security enhanced replacement drivers are being worked on since last
year, but not yet ready for prime time. It is possible with these
drivers to let scripts assign different device file permissions based on
the type of FireWire device ( - finer grained device security). These
drivers also
Syslog tells me this (I'm capturing in gutsy using dvgrab), which makes
me wonder if the thing is really fixed. From what I understand, it tells
me that the dv1394 device is not to be used in the near future, making
the whole thing break again? Does this bug need to be reopened?
Aug 2 00:36:37
Jeff, that's evidently a very old version of dvgrab. File a bug for the
dvgrab package --- it should be updated to version 2.1.
Yes, the dv1394 driver will eventually vanish. But there is no date set
for its removal yet; it depends on how fast the new alternative FireWire
stack which was merged
I wrote:
The unsupported isochronous request types in raw1394 that
dvgrab 1.x can use alternatively to dvgrab1394
should read ...to dv1394
dvgrab-2.1.tgz
should read dvgrab-2.1.tar.gz
--
use /dev/video1394, not /dev/raw1394
https://bugs.launchpad.net/bugs/6290
You received this bug
Ubuntu 7.04 and Kino 0.9.2 both use /dev/dv1394/0 which means that this
bug can be closed - so that's what I'm doing. It works fine for me with
my DV Camera capturing over firewire so I guess it works generally. If
you're settings are not using /dev/dv1394/0 then please reopen this bug.
If you
Fixed in Ubuntu 7.04
** Changed in: kino (Ubuntu)
Status: Confirmed = Fix Released
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
As I understood it, address based filtering could/would have been done
with the multiple files approach too. However the capabilities based
approach sounds really good. AFAICS it achieves basically the same in a
simpler way. Simpler = more secure.
I think the multi-file approach would allow to
A note on /dev/raw1394's security implications:
1. You cannot access local memory through raw1394, except for ROMs and
CSRs that are exposed to other nodes any way.
2. It is extremely hard to manipulate data on attached SBP-2 devices
(FireWire storage devices).
3. You can disturb operation of
Yes, you are right. Actually, a cheap setup to achieve #1 by #4 is to
have two FireWire controllers in the PC and connect them.
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
So there we go ;) access to /dev/raw1394 gives you access to the entire
host machine ... which is why only root can do it
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
Except if you don't load ohci1394 or load ohci1394 with the parameter
phys_dma=0. Switching physical DMA off will work fine with raw1394,
dv1394, video1394... It will just break sbp2 until I get
http://bugzilla.kernel.org/show_bug.cgi?id=6393 fixed. (It's not high on
my list, and it is a nuisance
I have developed a simple patch for raw1394 that I am just beginning to
test that addresses the raw1394 security issue in a way completely
different than Jody's proposal. One drawback to using many different
device files is the impact of that change on the libraries and
applications that will take
** Description changed:
- When trying to import video from an iee1394 device, kino is not able to
- access /dev/raw1394, so by default, if a user wants to import video from
- him/her camera, he/she needs to run kino with sudo o gsudo.
-
- I think that apt should print a warning like You should
Using 6.06 with Kino 0.9 the only thing giving me problems is that udev
doesn't seem to create any device node for ieee1394. At least neither
raw1394 nor dv1394 are created until I modprobe them.
Other than that small glitch with udev I can capture with dv1394 without
being root.
Should I file a
Yeah, linux1394 was late to the udev game, and I suspect the kernel name
will be a popular default for udev rule makers. I believe Dapper will be
a popular version for quite a while. Oh well, I will consider changing
the Kino default dv1394 device name or simply try a few popular names in
addition
We can consider the device name change for edgy, I suspect the only
reason we don't name them that is that nobody else did at the time we
froze our udev rules.
I'm against the idea of a group just for one device node, a firewire
group could be added and all *1394 devices placed into that though;
** Bug 46393 has been marked a duplicate of this bug
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Kino is not able to use video1394, and usage of video1394 for DV is
deprecated. The best solution at the moment is to create a new group for
raw1394.
On Thursday 25 May 2006 07:04, preciousp wrote:
Hope you don´t mind me asking but could you guide me (and others) on what
to do.
Is it.
1.
On Thursday 25 May 2006 01:59, preciousp wrote:
I think that in dapper it needs to use /dev/dv1394-0 rather than raw1394
(which is a security risk).
Can Ubuntu consider using dv1394/0 rather than dv1394-0 per the
convention attempting to be established at
I think that in dapper it needs to use /dev/dv1394-0 rather than raw1394
(which is a security risk).
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
I had a pretty good chat with Jody McIntyre back in Montreal about the
IEE1394 subsystem and what device nodes it exposes. I still think that
a USB-alike device node for each interface on each device is the right
solution; then we can assign groups and permissions on a per-interface
or per-device
Hope you don´t mind me asking but could you guide me (and others) on what to
do.
Is it.
1. Low risk - leave raw1394 as disk and don´t allow kino to access raw1394
to control camcorder
2. add user to the ¨disk¨ group - is this v.bad?
3. change raw1394 to video group - no no no ¨
I´m assuming
On your own machine, you may do whatever you like -- that's why these
things are configuration files. Obviously we have to ship things in a
safe configuration.
If the only firewire device you own is a video camera, changing the
group of the raw1394 device is probably appropriate.
--
use
full ack, but ATM I don't think we should allow access to /dev/raw1394 in a
default installation, it's just too dangerous. The easiest way to make it work
locally is to change 40-permissions.rules (change the group for 'raw1394' from
'disk' to 'video' or 'plugdev').
I know that this sucks,
Thank you for not revolting at my tone in my earlier response. I agree we need
to improve the kernel interface, and the issue has come up in the
linux1394-devel mailing list. However, I do not forsee a solution coming in the
near-to-mid-term. In the meantime, I was hoping to give users
Dan,
right, I have no idea about firewire video editing, but I believe I have some
idea about system security. A group 'raw1394' wouldn't change all that much,
since it still leaves loopholes to get full root privileges. If you trust your
computer, then people can already run kino etc. as
People who have no idea what they are talking about when it comes to Linux 1394
should not be trusted as an authority in this matter. What is so difficult
about creating a group named raw1394 and assigning group ownership of
/dev/raw1394 to it? Then, any user who trusts themselves on their own
31 matches
Mail list logo
