Bug 140734 - no read permission for /dev/nvram
no read permission for /dev/nvram
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-24 10:54 EST by petrosyan
Modified: 2014-03-16 22:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-10 09:33:41 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 petrosyan 2004-11-24 10:54:22 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:
ls -l /dev/nvram
crw-rw----  1 root root 10, 144 Nov 24 10:51 /dev/nvram

However tpb program ( http://www.nongnu.org/tpb/ ) needs read permission from /dev/nvram to work properly.

$ tpb
Unable to open device /dev/nvram: Permission denied


Version-Release number of selected component (if applicable):
udev-039-10.FC3.2

How reproducible:
Always

Steps to Reproduce:
install tpb from http://www.nongnu.org/tpb/


Additional info:
Comment 1 Harald Hoyer 2004-11-24 11:04:08 EST
put nvram in /etc/security/console.perms

$ rpm -qf /etc/security/console.perms
pam-0.77-65
Comment 2 Tomas Mraz 2004-11-24 12:56:05 EST
This isn't a good idea as it means that the ownership of the /dev/nvram would be
changed to console user and it would mean that the console user could overwrite
it's contents -> changing CMOS setup settings.

Maybe it would be better to change it's initial permissions in udev.permissions
to 644 to allow to read it by all.
Comment 3 Harald Hoyer 2004-11-25 04:19:17 EST
I am not sure, if I want to set it readable by all.. let's ask on the mailing
lists for opinions, concerns..
Comment 4 Dag Wieers 2005-01-02 03:02:03 EST
Any updates on this yet ?

What is the best way to have /dev/nvram available ? Do I still need to
provide /etc/udev/devices/nvram ?
Comment 5 Dag Wieers 2005-01-02 03:09:51 EST
The problem with tpb is that it needs /dev/nvram (by default), even
when the nvram module is not loaded.

Is it better to load the nvram module on boot and how can this be
arranged ?
Comment 6 Harald Hoyer 2005-01-03 09:30:41 EST
yes, the module should be loaded by kmodules, if it does not harm...
Comment 7 Bill Nottingham 2005-01-03 09:53:25 EST
It's not something that can be successfully probed at all. Any reason
it's not built static?
Comment 8 Dave Jones 2005-01-03 11:17:55 EST
none that I know of other than the usual 'bloat when not used by 99%
of the population'.
Comment 9 Bill Nottingham 2005-01-03 12:48:31 EST
True, but automatically loading it on bootup doesn't help that either. :/
Comment 10 petrosyan 2005-01-03 12:57:01 EST
nvram module gets loaded automatically when tpb accesses /dev/nvram.
The problem is that it has no read permissions.
Comment 11 Jeff Pitman 2005-01-05 07:48:27 EST
The nvram mod does *not* get loaded automatically.  I've tried.   
Putting "alias char-major-10-144 nvram" in modprobe.conf doesn't  
help the issue.  
  
I ended up throwing a script together in "/etc/dev.d/nvram" called  
perm.dev that executes when nvram is loaded.  Since its just my  
laptop, I just did 666.  (Course, who wants nvram on a multi-user  
sys anyway, eh?)  
  
The other thing is to throw in other="nvram" inside of rc.sysinit  
around line 151 to get it loaded on boot. 
 
(Maybe things like this are a good case for packages that configure 
the system for particular uses and/or particular laptops.) 
Comment 12 Bill Nottingham 2005-01-05 13:59:06 EST
Note that there is /etc/rc.modules for loading of other modules at
startup. I suppose there could be an /etc/sysconfig/modules instead.
Comment 13 Jeff Pitman 2005-01-06 02:10:25 EST
Comment associated with rc.modules:    
# Load modules (for backward compatibility with VARs)    
    
So, probably not to be used for forward-looking changes.    
   
I like the idea of /etc/sysconfig/modules. I think loading these  
types of modules via a config file external to the rc scripts is  
better--although, it creates yet-another-file-to-load-at-boot.  
  
As for the permissions problem, could a SELinux targeted policy be 
whipped together that would allow write access for tpb, KMilo, et al 
whilst denying for other processes?  
Comment 14 petrosyan 2005-02-10 09:33:41 EST
this bug has been fixed in tpb-0.6.3-2 from Fedora Extras

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