kmilo plugin unuseable

Bug #14413 reported by Chris Halls on 2005-03-22
8
Affects Status Importance Assigned to Milestone
kubuntu-meta (Ubuntu)
Medium
Jonathan Riddell

Bug Description

The IBM thinkpad latop control centre plugin does not work out of the box on the
live CD. Either we need to fix it or remove it. My suggestion would be to
remove it for now, since even if you run the commands suggested to enable the
module it still doesn't do much (maybe a logout/login will enable it?)

Jonathan Riddell (jr) wrote :

The steps are 1) modprobe nvram 2) chown root.ausergroup /dev/nvram 3) turn on kmilo thinkpad
in kcontrol 4) killall kded && kded to restart kded

If there is a way to have nvram loaded and read/write the user as default that would be great.

Matt Zimmerman (mdz) wrote :

What other sort of nastiness can be done with read/write access to an nvram
device? I seem to recall an earlier discussion about this for Ubuntu, the
result of which was that this wasn't safe

Matthew Garrett (mjg59) wrote :

Having /dev/nvram be writable allows the user to trash cmos settings (including
the less secure system password).

Chris Halls (halls) wrote :

Well I suppose that on the live CD, the user has gained root access effectively anyway so its no
more dangerous than if the user didn't have access.

However, what are the chances of something going wrong? e.g. milo trashes CMOS on an unsupported
new thinkpad model or some other machine that appears to be a thinkpad but isn't.

Do we really need to take this risk on the live CD? Do we really need this functionality on the
live CD itself? I'm wondering whether we should save this
just for the install CD, and turn this into a not-installed-by-default package that does all the
right things when explicitly installed by the admin.

Antti S. Lankila (alankila) wrote :

I would like that the system created nvram group by default. (Not only on live
cd but also in default install.) The current requirements to shoot yourself in
the foot are:

- create nvram group
- modprobe nvram
- adduser <your user> nvram
- log in with KDE and have kmilo turned on

I propose that we reduce the unobvious steps in the way and by default at least
create the nvram group (udev is already configured to expect the existence of
this group) so that users who want nvram are already pointed at new direction by
seeing the 0660 moded device file with root.nvram permissions. Additionally, I
do think nvram module should be mentioned at /etc/modules (because it's
"hardware" you got and you should have its driver loaded without action from
user's part).

Even if you disagree with the latter idea, it's okay. I really only want the
nvram group to be created. Without the group, even users who *want* to use kmilo
simply don't know how to setup their system correctly; witness the comment #1
from Jonathan Riddell, who advices the incorrect solution.

Users who want to use it still need to add themselves into the nvram group and
login again before things such as kmilo works. There is now some increased
danger for the root user, but then again, there are many files in /dev already
that cause awful results if randomly poked at, so nothing new there. As far as I
know, there should be no permanent damage to computer even in worst-case nvram
hacks because all it takes to repair the computer is to reset BIOS through the
on-board jumper to place it back to a known state. Okay, in principle users
might place computer into horrible overclocking settings, and try cook up their
hardware if their BIOS+hardware is sufficiently permitting, but it also is
overwhelmingly unlikely. I believe that most BIOSes have a checksumming
algorithm that determines whether the RAM has been meddled with, and will
reinitialize/ignore the RAM if its checksum does not match. (Because the RAM
state changes when the clear CMOS jumper is being used, and the BIOS needs to
reliably detect it and recover.)

Kenny Duffus (kduffus) wrote :

kmilo is no longer in the live aka desktop cd

Changed in kubuntu-meta:
status: Unconfirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.