On Wed, 27 Apr 2005, Alan Cox wrote: > On Mer, 2005-04-27 at 18:16, Greg KH wrote: > > -stable review patch. If anyone has any objections, please let us know. > > This patch is just wrong on so many different levels its hard to know > where to begin. > > 1. The auth for arbitary commands is CAP_SYS_RAWIO Valid complaint. > 2. "The SCSI command permissions were discussed widely on the linux > lists but this did not result in any useful refinement of the > permissions." - this is false. The process was refined, a table setup > was added and debugged. Any user having write access to the device is still allowed to send MODE SELECT (and some other commands useful for CD/DVD writers but being potentially dangerous to other). The assumption that _any_ command needed for burning CDs/DVDs is safe for all device types is ridiculous. This is why I don't consider the refinements useful. Controlling high-level access and pass-through with the same permissions is not a very good model. > Someone even wrote an fs for managing it that is > not yet merged. Yes. So we should wait for a miracle happen and it get merged? My patch is meant to fix the problems at low level until a more general fix is merged (if that ever happens). > Perhaps the patch author would care to re-read the > archives and submit a new patch if one is even needed > 3. Pleas explain *what* the specific consistency problems are OK. Once again.... Using MODE SELECT you can change the drive behaviour so that it may become practically useless for other users (and even break very quickly). A simple method is to disable drive buffering. The inconsistency here is that to the users the drive status is not what the system managers meant it to be. Another inconsistency comes from using commands moving the tape so that the tape driver does not know it. The tape driver provides users some status information about the tape head location (file and block number, BOT, EOF, etc.). This information is not valid if tape is moved using pass-through. The basic problem is that the driver for this kind of a sequential access device has to maintain some state information and it gets distorted if pass-through is used. One solution would, of course, be to interpret the commands and statuses going to/coming from pass-through but this is a quite heavy solution. OK. If the Linux solution to these kind of security problems in the not so central areas of kernel is to wait and see if the problem disappears without any action, I have to accept that. But I have tried... -- Kai - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
