This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 237537 - DVB ruleset don't work
DVB ruleset don't work
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-23 14:08 EDT by Peter Bieringer
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-24 05:11:19 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 Peter Bieringer 2007-04-23 14:08:55 EDT
Description of problem:
During investigation, why the permissions of the distributed rule file aren't
proper set and at least the defined group of a local ruleset is not applied I
found that there is a problem/bug somewhere.

Version-Release number of selected component (if applicable):
udev-095-17.fc6


How reproducible:
always


Steps to Reproduce:
1. remove dvb module
2. add adjusted ruleset, e.g.
KERNEL=="dvb",                  MODE="0660", GROUP="video"
SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", \
        NAME="%c", MODE="0660", GROUP="video"
3. send signal HUP to udevd
4. modprobe <dvb module>

Actual results:
Permissions of DVB related file entries in dev are 0600 with root:root

Expected results:
0660 root:video

The original definition in 50-udev.rules are also not working:

KERNEL=="dvb",                  MODE="0660"
SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", \
        NAME="%c", MODE="0660"

Additional info:

During debugging I found, that the rule is used, but some magic mechanism
(perhaps hotplug) is changing the permissions afterwards.

After "can't believe" I played around with options and found that all works
fine, if "last_rule" is used.

KERNEL=="dvb",                  MODE="0660", GROUP="video"
SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", \
        NAME="%c", MODE="0660", GROUP="video", OPTIONS="last_rule"

So perhaps the built-in ruleset should be adjusted in that way.
Comment 1 Peter Bieringer 2007-04-23 17:38:40 EDT
There is more unexpected magic going on here.

After clean booting, the permissions are still the unexpected 0600 root:root -
even if booted in runlevel 1!

But after removing all DVB modules and load them again via command line, the
permissions are are proper set to 0660 root:video

Can one explain me, how this can happen?

Another try after reboot: if I kill udevd and execute /sbin/start_udev
afterwards the permissions are also proper set according to configuration.

So using udev for DVB makes no sense at the moment, if I cannot get sure that
udev configuration during booting the system is proper used - this all makes no
sense.

BTW: how can I debug udev events during booting? Unfortunately, udevd starts
before syslog starts and all the info messages are pushed to console - too much
to see the DVB related ones.
Comment 2 Harald Hoyer 2007-04-24 05:11:19 EDT
pam_console is setting permissions here :)

$ cat /etc/security/console.perms*/*|fgrep dvb
<dvb>=/dev/dvb/adapter*/*
<console>  0600 <dvb>        0600 root
Comment 3 Peter Bieringer 2007-04-24 05:34:25 EDT
Thank you for pointing me to this magic mechanism.
BTW: I tried to overwrite this using:

# cat 10-dvb.perms 
<dvb>=/dev/dvb/adapter*/*

# permission definitions
<console>  0660 <dvb>        0660 root:video

But it won't help. Finally, I commented out the lines in 50-default.perms, now
the permissions are set as expected.

Is there any way to overwrite 50-default.perms without changing the file
(because after applying a pam update, changes have to be migrated manually).

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