(lkml readers: this concerns a security issue reported to debian by a
user of udev/aacraid. udev gives the aacraid devices the floppy group
because it reports block devices as 'removable'. See
http://bugs.debian.org/404927 for the entire thread).
On Wed, Jan 03, 2007 at 11:49:51AM +0100, Marco d'Itri wrote:
> On Jan 03, dann frazier <[email protected]> wrote:
>
> > Can you elaborate on what you believe the kernel is doing
> > incorrectly? My first guess would be the setting of the removable
> > flag, but aacraid claims to be setting this to prevent partition table
> > caching - do you believe that to be an incorrect usage?
> Yes, this looks like an abuse of the interface to me.
Ok, let's ask lkml
> > It seems like there is precedence for workarounds for older kernels in
> > permissions.rules, so would it be appropriate to add an override of
> > the default floppy rule for aacraid devices for compatability even if
> > this is a kernel bug?
> There are workarounds for bugs which are going to be fixed, but looks
> like this is going to stay forever...
> Are there other drivers in this situation?
I didn't turn up any otherwise when I was grepping yesterday, but my
search terms may have been too naive. I also checked a machine I had
w/ cciss - it did not have the removable flag set.
I found a message from Mark Salyzyn from last year that suggested this
was more pervasive:
http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/1231.html
Mark: Can you identify some of these other drivers?
--
dann frazier
The ips driver, indirectly via Firmware as it spoofs it's own inquiry
data, reports the Removable bit set in the inquiry response for the
arrays. The dpt_i2o driver similarly has the firmware constructing the
bit set. Some of the Array Bridges and external RAID boxes do the same
thing. I think the aacraid driver is the only RAID driver that has it's
own SCSI interpreter such that this coded activity surrounding the
removable status is visible, however it currently responds by setting
the removable scsi_device field when the READ_CAPACITY is reported.
About four years ago and before it would actually set the RMB bit in the
Inquiry response like the other array drivers.
If a new interface was added to tell the scsi layer to re-read the
partition table, then the aacraid driver, at least, could stop reporting
the array as removable. However, we loose the 'busy check' that results
from the upper layers doing media locking when the removable device is
mounted; the array management applications would then be permitted to
change an array while it is in use. We would need some other way of
asking the upper layers if the device is in use (open or mounted), that
apparently is impossible given the new design of the scsi layers
(Christoph?).
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: dann frazier [mailto:[email protected]]
> Sent: Wednesday, January 03, 2007 10:58 AM
> To: Salyzyn, Mark; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]
> Subject: udev/aacraid interaction - should aacraid set 'removable'?
>
>
> (lkml readers: this concerns a security issue reported to debian by a
> user of udev/aacraid. udev gives the aacraid devices the floppy group
> because it reports block devices as 'removable'. See
> http://bugs.debian.org/404927 for the entire thread).
>
> On Wed, Jan 03, 2007 at 11:49:51AM +0100, Marco d'Itri wrote:
> > On Jan 03, dann frazier <[email protected]> wrote:
> >
> > > Can you elaborate on what you believe the kernel is doing
> > > incorrectly? My first guess would be the setting of the removable
> > > flag, but aacraid claims to be setting this to prevent
> partition table
> > > caching - do you believe that to be an incorrect usage?
> > Yes, this looks like an abuse of the interface to me.
>
> Ok, let's ask lkml
>
> > > It seems like there is precedence for workarounds for
> older kernels in
> > > permissions.rules, so would it be appropriate to add an
> override of
> > > the default floppy rule for aacraid devices for
> compatability even if
> > > this is a kernel bug?
> > There are workarounds for bugs which are going to be fixed,
> but looks
> > like this is going to stay forever...
> > Are there other drivers in this situation?
>
> I didn't turn up any otherwise when I was grepping yesterday, but my
> search terms may have been too naive. I also checked a machine I had
> w/ cciss - it did not have the removable flag set.
>
> I found a message from Mark Salyzyn from last year that suggested this
> was more pervasive:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/1231.html
> Mark: Can you identify some of these other drivers?
>
>
> --
> dann frazier
>
>
On Wed, Jan 03, 2007 at 12:17:47PM -0500, Salyzyn, Mark wrote:
> The ips driver, indirectly via Firmware as it spoofs it's own inquiry
> data, reports the Removable bit set in the inquiry response for the
> arrays. The dpt_i2o driver similarly has the firmware constructing the
> bit set. Some of the Array Bridges and external RAID boxes do the same
> thing.
Thanks Mark. If you have any of these devices, could you help supply
the udevinfo information? Our udev maintainer has asked for this so
that he can workaround this issue by special casing these
devices. (See http://bugs.debian.org/404927 for details).
--
dann frazier
I do not have any close at hand (cleaned out the hardware closet to
hazardous waste) :-(
But, as far as I am concerned :-), if it says 'DPT' or 'Adaptec' as the
manufacturer's name portion of the inquiry field, or has 'RAID' or
'Array' somewhere in the product name inquiry field, you have covered
most, if not all, of the possibilities I can come up with!
Hope that helps.
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: dann frazier [mailto:[email protected]]
> Sent: Friday, January 05, 2007 3:14 PM
> To: Salyzyn, Mark
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]
> Subject: Re: udev/aacraid interaction - should aacraid set
> 'removable'?
>
>
> On Wed, Jan 03, 2007 at 12:17:47PM -0500, Salyzyn, Mark wrote:
> > The ips driver, indirectly via Firmware as it spoofs it's
> own inquiry
> > data, reports the Removable bit set in the inquiry response for the
> > arrays. The dpt_i2o driver similarly has the firmware
> constructing the
> > bit set. Some of the Array Bridges and external RAID boxes
> do the same
> > thing.
>
> Thanks Mark. If you have any of these devices, could you help supply
> the udevinfo information? Our udev maintainer has asked for this so
> that he can workaround this issue by special casing these
> devices. (See http://bugs.debian.org/404927 for details).
>
> --
> dann frazier
>
>