Bug 240770

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.