Bug 147306 - tpb is not udev-aware
tpb is not udev-aware
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tpb (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-06 17:44 EST by Matthew Saltzman
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.6.3-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-09 17:02:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Saltzman 2005-02-06 17:44:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
After rebooting, /dev/nvram is gone.

Version-Release number of selected component (if applicable):
tpb-0.6.3-1

How reproducible:
Always

Steps to Reproduce:
1. Install tpb RPM
2. Reboot
3. ls -l /dev/nvram
    

Actual Results:  File not found

Expected Results:  crw-r--r--  1 root root 10, 144 Dec 11 21:27 /dev/nvram

Additional info:

I worked around this by creating /etc/udev/devices/nvram and adding 
/etc/udev/permissions.d/40-nvram.permissions containing

nvram:root:root:0644

The RPM should include these files.
Comment 1 Ville Skyttä 2005-02-06 18:18:26 EST
Yep, known problem, unfixed because I don't quite like that way of
"fixing" it nor have I come up with better ideas.

nvram:root:root:0644 is not very good, because non-local users have no
business reading nvram at least as far as tpb is concerned; a better
default would be 0600 and console.perms modification to give the
console user access to nvram.  But console.perms is too inflexible,
I'm not going to modify it on the fly from the package, and there's no
console.perms.d :(  (But a RFE to get one is Bugzilla'd).

I would probably name the permissions.d snippet *-tpb.permissions or
*-tpb-nvram.permissions to avoid possible (but unlikely) collisions
with other packages.

Thoughts?
Comment 2 Matthew Saltzman 2005-02-06 19:09:43 EST
I agree with renaming the permissions file.  I like
*-tpb-nvram.permissions myself.  How to decide what the digits should be?

I see your point about the permissions, but I'd counter that

(1) The permissions in the original package are the same, so the fix
is no worse than doing nothing from a security viewpoint.
(2) Is it really a security risk?
(3) As it stands, the package doesn't work at all (after reboot), so
users need to install some sort of fix themselves.  I'd wager that for
anyone who thinks they know what they are doing, this is the fix they
would use.  And anyone who doesn't is out of luck.

Can we use this fix for now and do something smarter when
console.perms gets fixed?
Comment 3 Ville Skyttä 2005-02-09 17:02:25 EST
Fixed in 0.6.3-2 as suggested, thanks.  I chose 49 for the permissions.d digits.

If you can think of a better way of handling the permissions, let me know.  I'm
not entirely comfortable with allowing everyone access to /dev/nvram as I don't
know what might be available from there.  But as you said, this update does not
make things any worse than they used to be in the previous one.

Oh, and the console.perms.d RFE is bug 135093.
Comment 4 petrosyan 2005-05-11 01:14:55 EDT
I get the following error:
$ tpb
Unable to open device /dev/nvram: Permission denied

when I run tpb in FC4T3 with all the latest updates
tpb-0.6.3-2
Comment 5 Ville Skyttä 2005-05-16 02:55:38 EDT
FC4t3 problem should be fixed in the upcoming 0.6.3-4.

Next time, please open a new bug report for a new bug, or at least reopen the
old one if you choose to report it in one; that makes it easier for people to
track bug statuses.  Thanks in advance.
Comment 6 petrosyan 2005-05-21 20:53:26 EDT
When is tpb-0.6.3-4 going to be released?
Comment 7 Ville Skyttä 2005-05-22 05:20:51 EDT
According to the timestamps, it was pushed to the development repository last
Friday.

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