Subject: Re: Partition tables (was: Re: Another changer, another changer problem)
To: None <current-users@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: current-users
Date: 10/15/1998 14:40:43
>>> struct diskaccess da[1]; /* contains a struct diskpart */
>>> da->disk="sd0";
>>> fd=open("/dev/diskpart", O_RDWR)
>>> ioctl(fd, DKIOCGDTAB, &da);
>> The first problem that comes to mind with this is that it means that
>> anyone who can open /dev/diskpart for read or write can read or
>> write *any* disk's partition table.
> 1. "No, you're reading more into what I wrote than what is there. I
> was trying to imply 'O_RDWR or O_RDONLY as appropriate.'
Well, yeah, but there's still no way to control permissions on a
per-disk basis.
> But you've gotta admit that there's a certain degree of elegance in
> being able to do it this way:
> - you only need one more device.
> - the kernel side handles the routing.
Right. And actually, a way to resolve it occurred to me. Instead of
giving it a disk name, give it a path to a device special file for any
of that disk's partitions. This will allow the kernel to identify the
relevant disk unambiguously and will allow real permissions checking
(except for the case where you may want to allow someone to write a
certain partition but not to write elsewhere on the disk, and in
particular not write the partition table - but as I understand it if
that's what you want' you're screwed at present anyway, so we don't
lose anything). My first thought was to say "give it a fd open on the
device", but if we don't have a RAW_PART, there is no device you can
open until there's a partition table, leading to a chicken-and-egg
dilemma when you have an unlabeled disk to deal with. Passing a path
to a device special file allows the diskpart driver to identify the
disk without actually having to open it (which would fail).
There is a problem in that currently, only the disk's driver knows how
to break a minor number down into a <unit,partition> pair - but a
similar problem arises if you try to do something with "sd0" anyway,
and I'd prefer to see that code moved out into something common anyway,
either by the "disk0 at sd0" sort of thing or something akin to an MI
disksubr.c....
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B