Description of problem: The old firewire stack created a /dev/raw1394 device that was chowned to the user when they logged in. The new stack provides /dev/fw? instead (at least, as far as I can tell, this is the analogous interface). These devices aren't chowned at login time, so users are unable to access them. I believe the simple fix is to update /etc/security/console.perms.d/50-default.perms to include /dev/fw* on the <raw1394> line. Version-Release number of selected component (if applicable): pam-0.99.7.1-5.fc7 How reproducible: 1) install libiec61883-utils 2) strace plugreport (as non-root), note the following line: open("/dev/fw0", O_RDWR) = -1 EACCES (Permission denied) 3) ll /dev/fw* crw------- 1 root root 251, 0 2007-05-20 21:22 /dev/fw0 crw-rw----+ 1 root root 251, 1 2007-05-20 21:22 /dev/fw1 When run as root, plugreport actually returns info about what it sees: Host Adapter 0 ============== Node 0 GUID 0xf0219500009521f0 ------------------------------ libiec61883 error: error reading oMPR libiec61883 error: error reading iMPR Node 1 GUID 0x000ce5fffe719455 ------------------------------ oMPR n_plugs=1, data_rate=2, bcast_channel=63 oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0 channel=0, data_rate=2, overhead_id=0, payload=376 iMPR n_plugs=0, data_rate=2 Node 2 GUID 0x0019e3fffe2da720 ------------------------------ libiec61883 error: error reading oMPR libiec61883 error: error reading iMPR Of course, trying to actually capture data off of node 1 (my firewire cable box) results in a segfault (works in fc6), but that's another bug... :)
I suppose this affects Fedora 7 as well, so update (post release will be enough?) should be done there too?
The new stack lets us do finer grained permission management than the old stack, in that we can selectively chown device files based on what kind of device it corresponds to. The interesting case here is storage devices, where we probably want to disable non-priviledged access, that is, not chown it. I don't know how well pam-console can support this, but if it's possible we should not chown devices that has a sysfs fwx.y subdir with a driver link to sbp2. Alternatively we can whitelist the devices we chown and restrict it to IIDC cameras (isight and others) and AV/C devices (camcorders, settop boxes and other consumer media hardware).
(In reply to comment #1) > I suppose this affects Fedora 7 as well, so update (post release will be > enough?) should be done there too? Whoops, I'd actually meant to file this for F7, in hopes maybe we could sneak in an update prior to release, if possible. Not really a release blocker though, a post-release update wouldn't be a big deal.
pam_console decides purely on the path name of the device. Perhaps the class of the device could be somehow reflected in its name? Either directly or by making/not making a specifically named symlink. As it is not release blocker and the fix is still not perfectly defined this will have to wait post release.
Created attachment 157758 [details] udev script to detect different types of firewire units
Created attachment 157759 [details] udev rule file to create symlinks to various types of firewire units
Created attachment 157760 [details] Patch to console.perms.d/50-default.perms to chown consumer-type fw devices
Okay, these three attachments provide a solution for this. I split them up because the files probably belong in different packages. I added one udev rule to run a script "/lib/udev/fw_unit_symlinks.sh" for each firewire device. Since the unit spec IDs are visible only in child nodes of the firewire device, I think a script is the only way to get at this information. The script returns to stdout a list of symlinks that should be created. They are of the form sbp2-%n, avc%n, iidc%n, or vendorfw%n, depending on what units are present in the device. The final attachment is a patch to pam-console rules so that avc, iidc, and vendorfw devices are chowned to the console owner. Kristian, I suspect you have a large collection of interesting firewire devices so I would appreciate it if you could test this to make sure it works for your devices.
(Adding harald, udev maintainer) (In reply to comment #8) > Okay, these three attachments provide a solution for this. I split them up > because the files probably belong in different packages. David, thanks a lot for doing this. It looks good and is more or less what I had in mind. > I added one udev rule to run a script "/lib/udev/fw_unit_symlinks.sh" for each > firewire device. Since the unit spec IDs are visible only in child nodes of the > firewire device, I think a script is the only way to get at this information. > The script returns to stdout a list of symlinks that should be created. They > are of the form sbp2-%n, avc%n, iidc%n, or vendorfw%n, depending on what units > are present in the device. I think it's a fine solution. Maybe we can improve on the script but it's a good start and I think we should just drop it in. I would do something like for i in "${SYSFS}${DEVPATH}/${NAME}.*/specifier_id"; do SPEC_ID=$(cat $i) ... done Do we need to create symlinks for sbp2 devices, though? When would that be useful? I'm not familiar with the vendorfw rule, what's that about? > The final attachment is a patch to pam-console rules so that avc, iidc, and > vendorfw devices are chowned to the console owner. > > Kristian, I suspect you have a large collection of interesting firewire devices > so I would appreciate it if you could test this to make sure it works for your > devices. I'll give it a try here. I mostly have storage devices, though. cheers, Kristian
(In reply to comment #9) > I think it's a fine solution. Maybe we can improve on the script but it's a > good start and I think we should just drop it in. I would do something like > > for i in "${SYSFS}${DEVPATH}/${NAME}.*/specifier_id"; do > SPEC_ID=$(cat $i) > ... > done > Yeah, that's fine too. Just be careful to handle the case where there is no fw*.* subdirectory so that you don't get an error in the script. > Do we need to create symlinks for sbp2 devices, though? When would that be > useful? I'm not familiar with the vendorfw rule, what's that about? I figured we might as well create symlinks for any device type that we know about (including sbp2) so that users can write their own rules if they want to. As for vendorfw, I don't know what it is either, but I got it from this list: http://www.1394ta.org/Technology/Specifications/AssignedCodes.htm -David
s.th. like this? #!/bin/sh SYSFS=/sys NAME=$1 NUM=$2 for i in "${SYSFS}${DEVPATH}/${NAME}.*/specifier_id"; do if [ ! -f $i ]; then continue fi SPECID="`cat $i`" if [ $((SPECID)) -eq $((0x00609e)) ]; then echo -n "sbp2-${NUM} " elif [ $((SPECID)) -eq $((0x00a02d)) ]; then SWVER="`cat ${i%/specifier_id}/version`" if [ $((SWVER)) -ge $((0x100)) -a $((SWVER)) -lt $((0x110)) ]; then echo -n "iidc${NUM} " elif [ $((SWVER)) -eq $((0x10001)) ]; then echo -n "avc${NUM} " elif [ $((SWVER)) -ge $((0x14000)) -a $((SWVER)) -le $((0x14001)) ]; then echo -n "vendorfw${NUM} " fi fi done echo
(In reply to comment #11) > s.th. like this? ... Oh yeah, if there's no fwX.Y dir it expands to the literal glob so we need the -f test... gah. Ok, yup, looks good, thanks.
So the user firewire devices are added to pam_console in pam-0.99.8.1-1.fc8.