Bug#563852: marked as done (thinkpad_acpi: LED restriction does not add safety, please enable CONFIG_THINKPAD_ACPI_UNSAFE_LEDS)
Your message dated Tue, 26 Jan 2010 23:51:53 +0100
with message-id <20100126225152.GA4809@galadriel.inutil.org>
and subject line Re: thinkpad_acpi: LED restriction does not add safety, please enable CONFIG_THINKPAD_ACPI_UNSAFE_LEDS
has caused the Debian Bug report #563852,
regarding thinkpad_acpi: LED restriction does not add safety, please enable CONFIG_THINKPAD_ACPI_UNSAFE_LEDS
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
563852: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563852
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-2.6
Severity: normal
The kernel guys decided it would be a good idea to cripple thinkpad_acpi by
not allowing the state of some hardware LEDs to be set, like the dock and
battery. They say that allowing these LEDs to be set can make users perform
actions dangerous to the hardware because firmware information might get lost.
I think that this change does not add safety at all, because the "unaware"
user which they reference in the docs doesn't play around with the LEDs anyway.
The LED devices are root writable only anyway, so evil guy wanting to destroy
other people's laptop could just load a fixed kernel module to control the
LEDs. The option is just a PITA for people that want to control the LEDs for
their own purposes, because they have to rebuild kernel modules. (No it's not
even a module load option like with the fan control switch, even though doing
funny things with the fan can cause much more damage to the hardware than
doing things to the LED.)
So there is no advantage in restricting access to the LEDs and therefore I'd
be thankful if future versions of the Debian kernel were built with
CONFIG_THINKPAD_ACPI_UNSAFE_LEDS enabled.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Lars Stoltenow wrote:
> So there is no advantage in restricting access to the LEDs and therefore I'd
> be thankful if future versions of the Debian kernel were built with
> CONFIG_THINKPAD_ACPI_UNSAFE_LEDS enabled.
Sorry, we're playing on the safe side here. Even the Kconfig text is pretty
pretty: "Never enable this option on a distribution kernel."
Cheers,
Moritz
--- End Message ---
Reply to: