Bug 305801 - dynamic ACL issues
dynamic ACL issues
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ConsoleKit (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Julian Sikorski
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 246107 F8Test3
  Show dependency treegraph
 
Reported: 2007-09-25 14:28 EDT by Jesse Keating
Modified: 2013-01-09 21:39 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2007-09-25 14:28:52 EDT
It appears that ConsoleKit isn't emitting the right signal when sessions go
inactive/active so that ACLs get updated accordingly.  This manifests itself on
my system by not having correct ACLs to access the sound hardware.

http://jkeating.fedorapeople.org/lumos-9-25.messages /var/log/messages with hal
being verbose
http://jkeating.fedorapeople.org/lumos-dbus.monitor dbus output with a couple
session changes (changing to VT1 where root is logged in, back to VT7 (x) where
jkeating is logged in)
Comment 1 David Zeuthen 2007-09-25 15:35:42 EDT
This bug is caused by thinkfinger; it errornously merges the access_control
capability (from a fdi file provided by this package), the access_control.file
property but doesn't set the property access_control.type.

Anyway, This means the entry is invalid and as a result hal-acl-tool craps out
and aborts changing any properties. This is not optimal so I've fixed
hal-acl-tool to cope with this

http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=66cb813715538818770df7685ab2be4d85d75a07

Either way, as described above the bug is in thinkfinger. When removing the fdi
file provided by thinkfinger, Jesse's system started working as intended.
Comment 2 Julian Sikorski 2007-09-25 15:39:39 EDT
The .fdi file wasn't created by me, CCing the author.
Comment 3 Mike Bonnet 2007-09-25 16:59:11 EDT
access_control.type isn't necessary on F7 hal, right?  What should the value be
on F8?  This is for the fingerprint reader USB device.

While we're at it, where should the .fdi file go?  Is it ok to drop it into
/usr/share/hal/fdi/policy/10osvendor/ ?
Comment 4 David Zeuthen 2007-09-26 12:21:25 EDT
You need to provide both a .fdi file and a .policy file like the ones pasted
below. The fdi file should go in /usr/share/hal/fdi/policy/10osvendor/ and start
with 00-. For both files, change my-random-device to e.g. thinkfinger and update
the match criteria (e.g. the USB id's) for the device accordingly.

System administrators can now lock down access via the PolicyKit action
org.freedesktop.hal.device-access.my-random-device (or what you ended up calling
it) to only the users he wants using the /etc/PolicyKit/PolicyKit.conf. The
defaults are in the .policy file and are currently set to only grant access to
active console users. That's probably what you want.

Hope this helps.

[root@oneill ~]# cat
/usr/share/hal/fdi/policy/10osvendor/00-acl-for-my-random-device.fdi 
<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
  <device>
    <!-- grant access to a random device -->
    <match key="usb_device.vendor_id" int="0x46d">
      <match key="usb_device.product_id" int="0xc505">
        <append key="info.capabilities" type="strlist">access_control</append>
        <merge key="access.control.file"
type="copy_property">linux.device_file</merge>
        <merge key="access.control.type" type="string">my-random-device</merge>
      </match>
    </match>
  </device>
</deviceinfo>


[root@oneill ~]# cat /usr/share/PolicyKit/policy/my-random-device.policy<?xml
version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">

<policyconfig>
  <action id="org.freedesktop.hal.device-access.my-random-device">
    <description>Directly access My Random Device</description>
    <message>System policy prevents access to My Random Device</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>
</policyconfig>
Comment 5 David Zeuthen 2007-09-26 12:46:50 EDT
(changing Summary to something more accurate)
Comment 6 Mike Bonnet 2007-09-27 02:32:33 EDT
I've created a new build for F8 that fixes the .fdi file and adds the PolicyKit
policy provided by davidz.  Could someone running F8 with fingerprint reader
hardware test these packages?  With the latest selinux-policy installed, and the
requisite line in /etc/pam.d/system-auth, these packages should work OOTB.

http://koji.fedoraproject.org/koji/buildinfo?buildID=19705

Let me know how these work, I'd really like to get them into test3.

I've also created new packages for F7 that fix the location of the .fdi file. 
These work for me with the latest selinux-policy (selinux-policy-2.6.4-45.fc7).
 Unless there are any issues with them, I'm going to push them as an F7 update
once selinux-policy gets pushed.

http://koji.fedoraproject.org/koji/buildinfo?buildID=19698

Thanks!
Comment 7 Jesse Keating 2007-09-27 07:44:38 EDT
The f8 build fixes it for me, I can now use my reader from the screensaver. 
Nice work!

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