Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

From: Joerg Schilling (schilling_at_fokus.fraunhofer.de)
Date: 08/22/04

  • Next message: Joerg Schilling: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices"
    Date:	Sun, 22 Aug 2004 13:56:44 +0200
    To: schilling@fokus.fraunhofer.de, der.eremit@email.de
    
    

    Let me give some additional remarks to clear up things:

    Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

    > Pascal Schmidt <der.eremit@email.de> wrote:

    > > The previous Linux implementation allowed users with *read* access
    > > to the device to send arbitrary SG_IO commands. Giving read permission
    >
    > This is of course a kernel bug - but it could be easily fixed.
    > My scg driver for SunOS requires write permissions since it has been
    > created in August 1986.

    Not checking for Write access permissions at this place is a typical mistake
    made by novice programmers, so I never thought this could be in Linux.....

    > > to normal users is quite common, to allow them to run isosize or play
    > > their freshly burned SVCDs with mplayer.
    >
    > So changing the kernel to require write permissions would be a simple fix that
    > would help without breaking cdrtools as libscg of course opens the devices with
    > O_RDWR.

    If Linux still noes not check for write permissions, I would consider there is
    still a bug.

    If there is a list of "aparently safe" SCSI commands that are allowed to be
    executed, then there is another bug in Linux. The only SCSI command that could
    be called safe if Test Unit Ready and even this only if not send more then once
    every few seconds.

    There are several SCSI commands that look safe but would result in coasters
    if issued while a CD or DVD is written.

    Conclusion: It makes no sense to start implementing a fine grained security
    model before basic secutity has been done correctly.

    The best immediate fix for the problem is to just check for read & write
    permissions on the file descriptor and otherwise revert to how it has been
    before 2.6.8.

    Jörg

    -- 
     EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
           js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
           schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
     URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
    -
    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/
    

  • Next message: Joerg Schilling: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices"

    Relevant Pages

    • Kernel BUG at fs/mpage.c:489
      ... I found a kernel bug. ... Internal Connector Type: On Board IDE ... Internal Reference Designator: SECONDARY IDE/HDD ...
      (Linux-Kernel)
    • Re: CD writing in future Linux (stirring up a hornets nest)
      ... On Monday 20 February 2006 11:05, Joerg Schilling wrote: ... We all know that filtering is not needeed to fix a bug. ... SCSI and ATA/ATAPI bus on Linux. ...
      (Linux-Kernel)
    • GlobalAddAtom Bug Solved (I guess its a "feature")
      ... I'm reposting an issue I had with GlobalAddAtom not functionning due to what ... I believed to be a Kernel Bug. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Access 97 Security issue Cant make a MDE
      ... > table to get it to work for non-admin users, I assumed this was a bug. ... It is a bug in Access 97. ... The permissions needed on the MSysModules2 table for non-Admin group users ... table in order for the non-Admin group users to open the Access 97 MDE, ...
      (microsoft.public.access.security)
    • Re: kernel BUG at mm/rmap.c:483!
      ... Subject: kernel BUG at mm/rmap.c:483! ... > such experiments on this server, and will revert to 2.4 for now. ... and I'm worried that it will cost me a lot of my ...
      (Linux-Kernel)