Bug 240770 - Firewire device nodes in new stack not chowned at login time
Firewire device nodes in new stack not chowned at login time
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-21 11:46 EDT by Jarod Wilson
Modified: 2007-11-30 17:12 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-24 13:00:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
udev script to detect different types of firewire units (681 bytes, text/plain)
2007-06-25 10:25 EDT, David Moore
no flags Details
udev rule file to create symlinks to various types of firewire units (81 bytes, text/plain)
2007-06-25 10:27 EDT, David Moore
no flags Details
Patch to console.perms.d/50-default.perms to chown consumer-type fw devices (593 bytes, patch)
2007-06-25 10:29 EDT, David Moore
no flags Details | Diff

  None (edit)
Description Jarod Wilson 2007-05-21 11:46:05 EDT
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... :)
Comment 1 Tomas Mraz 2007-05-21 12:07:14 EDT
I suppose this affects Fedora 7 as well, so update (post release will be
enough?) should be done there too?
Comment 2 Kristian Høgsberg 2007-05-21 12:14:25 EDT
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).
Comment 3 Jarod Wilson 2007-05-21 13:10:02 EDT
(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.
Comment 4 Tomas Mraz 2007-05-21 13:12:39 EDT
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.
Comment 5 David Moore 2007-06-25 10:25:49 EDT
Created attachment 157758 [details]
udev script to detect different types of firewire units
Comment 6 David Moore 2007-06-25 10:27:06 EDT
Created attachment 157759 [details]
udev rule file to create symlinks to various types of firewire units
Comment 7 David Moore 2007-06-25 10:29:12 EDT
Created attachment 157760 [details]
Patch to console.perms.d/50-default.perms to chown consumer-type fw devices
Comment 8 David Moore 2007-06-25 10:35:53 EDT
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.
Comment 9 Kristian Høgsberg 2007-06-26 11:52:07 EDT
(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
Comment 10 David Moore 2007-06-26 19:16:25 EDT
(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
Comment 11 Harald Hoyer 2007-06-27 06:45:48 EDT
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
Comment 12 Kristian Høgsberg 2007-06-27 10:29:59 EDT
(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.
Comment 13 Tomas Mraz 2007-07-24 13:00:09 EDT
So the user firewire devices are added to pam_console in pam-0.99.8.1-1.fc8.

Note You need to log in before you can comment on or make changes to this bug.