Jörg
Dave Platt wrote:
There is no need to discuss this. The important facts to learn from me is:
I write cdrecord in a way that allows me to support as many features as
possible.
I write cdrecord in a way that allows me to know as much on the drive in
advance as possible.
Jörg,
Would you be willing to provide a specific and complete list
(e.g. in a text file, as part of the cdrtools distribution) of
the set of SCSI commands that you consider to be necessary
and/or desireable for cdrtools? If the commands were listed
all in one place, it would be much easier for people (Linux kernel
maintainers, non-Linux kernel people, and J. Random Kibitzers)
to do a proper security analysis, and then (as necessary) make
a clean decision as to which commands are truly safe for non-root
write access and which may not be.
I will venture a guess that the answer will be that as usual the answer
will be one or more of (a) Linux developers hate me and wouldn't do it
anyway, (b) you can get it from me source code, or (c) if anyone was as
smart and wonderful as Jörg they wouldn't have to be told.
I've given up being polite and reasonable with Jörg, he's smart enough
to write code that works, everyone else has.
This list could either be done by enumerating the commands which
are necessary, or could be done by saying "All of the MMC-3 commands,
except for the following", or somewhere in between. The critical
thing would be to have a fully-described list of the commands,
independent of the current source-code implementation of
cdrtools or any other software package.
In looking at the Linux code which implements the security
rules, I can see at least two things which could be done, and
a third might be worthwhile:
[1] The restrictions are implemented in one way in the /dev/sg
generic SCSI driver (older code), and another way in the
general-purpose block-device driver (newer code).
It would seem to make good sense to factor this code out,
and have just a single implementation (probably based on the
newer code, which appears to be more flexible and more
MMC-3-friendly).
Including the ide-scsi driver here would be desirable as well.
[2] The list of MMC-3 commands allowed for non-root write access
in the block device driver might be expanded.
But would have to have a big quirks file to allow commands in the
vendor group, which do one thing on one hardware, and something
undesirable on other hardware.
[3] The list of commands might be made extensible at run time,
possibly on a per-device basis. This might be done via the
Linux /proc or /sys interfaces. The built-in list could be used
in most cases, but the individual system owner could extend it
if a particular drive needed a drive-specific command for
full-featured operation.
This would be a start, but it doesn't address the real problem, which
is knowing which commands are safe on which hardware. And other than
allowing a more complete subset of MMC commands, that's something which
needs to be done at user level, or at least is best done there.
The obvious solution would be to set trusted programs setuid root, but
that is carefully blocked, resulting in many thing other than CD
burning now needing root access. I don't regard that as a step forward.
My suggestion would be to add an ioctl, like SET_SCSI_UNFILTERED, which
can only be used as root, and which would allow SCSI commands sent a
device to be persistently set unfiltered. At least that lets the boot
code set ownership and permissions at boot time, and puts the choice of
appropriate access back in the hands of the administrator. It would
allow individual group membership or trusted programs setgid to fully
access the device. Yes, that implies allowing setgid to work.
I've added lkml to the cc list, there's been enough discussion related
to this on that list that I think it's relevant.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
|