JörgDave Platt wrote:
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.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'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:  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.
 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.
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 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.
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 <email@example.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979