Red Hat Bugzilla – Bug 140734
no read permission for /dev/nvram
Last modified: 2014-03-16 22:50:49 EDT
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.
Unable to open device /dev/nvram: Permission denied
Version-Release number of selected component (if applicable):
Steps to Reproduce:
install tpb from http://www.nongnu.org/tpb/
put nvram in /etc/security/console.perms
$ rpm -qf /etc/security/console.perms
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.
I am not sure, if I want to set it readable by all.. let's ask on the mailing
lists for opinions, concerns..
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 ?
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
yes, the module should be loaded by kmodules, if it does not harm...
It's not something that can be successfully probed at all. Any reason
it's not built static?
none that I know of other than the usual 'bloat when not used by 99%
of the population'.
True, but automatically loading it on bootup doesn't help that either. :/
nvram module gets loaded automatically when tpb accesses /dev/nvram.
The problem is that it has no read permissions.
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.)
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 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?
this bug has been fixed in tpb-0.6.3-2 from Fedora Extras