Joerg Schilling wrote:
Bill Davidsen <[EMAIL PROTECTED]> wrote:
It seems that you missd the fact that it has been introduced 2 weeks before
cdrtools-2.01-final came out and people on LKML did complain that I did not
cause cdrtools to become unstable from introducing untested code.
Announced (in case of an incompatible change) means:
- prominent developers of code that uses the interface that is to
be changed need to be informed a sufficent time _before_ the
incompatible change is applied.
In general, it would make Linux a mature project if such changes would be
discussed for being reasonable with other people ( e.g. with experienced
programmers like me).
This was not a change made because it would be nice, it was made because
it became public information that anyone who could burn could change the
firmware. Security fixes sometime do have to be done quickly, evil
people do tend to jump on any opening in the time between a
vulnerability becoming public and being fixed.
This is unfortunately nonsense.
If you have a security problem, you usually fix the problem and to not
change the interfaces. In special when it was posible to fix the security
problem _whithout_ breaking the interface as in our case:
The Security problem was that the Linux kernel did not check for write
permission in order to allow SCSI generic commands to be send.
The onvious fix wouild have been to change the kernel to correctly require
write permission on a fd for the SD_IO ioctl.
Think about that one for a minute... you need to write the "seek" and
"send data" commands to use the CD at all, at least if you use the sg
interface. So just blindly blocking write would leave sg users unable to
use the device at all. You really need a bit of cleverness here, just
checking write permissions isn't enough.
--
bill davidsen <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]