Messages in this thread | | | From | "J. Dow" <> | Subject | Re: [patch] My AMD IDE driver, v2.7 | Date | Mon, 11 Mar 2002 22:26:46 -0800 |
| |
From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> Your proposal sounds 100% ok to me... > > For the details of the userspace interface (for both ATA and SCSI), my > idea was to use standard read(2) and write(2). > > Any number of programs can open /dev/ata/hda/control or > /dev/scsi/sdc/control. write(2) submits requests, read(2) consumes > command responses, perhaps buffering a bit so that multiple responses > are not lost if userspace is slow. > > Maybe it's a cheesy way to avoid ioctl(2), maybe not...
Jeff, from a security aspect would it perhaps be better to have the filter always in place and load rule sets through a rigidly controlled interface? This gives a control hook for non-Unixoid security model control over the interface filtering. The filter module would have the lower level interfaces all opened exclusively so there would be no paths around the filter. I propose that the rule sets, for each device's instance of the filter interface, could be changed to include anything from a null set to forbidding anything past fully controlled read and write with no raw IO. One specific entity could be allowed to make the changes and no others. This gives a single interface for verifying signatures on filter data sets, as well.
{^_^}
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |