If a normal (not root) user attempts an operation to a CD-ROM that fails (such as accidentally attempting to write to the drive), the next access of any type to the drive by any user will hang until reboot. This should be considered a denial-of-service security problem. Fix: Not known. This really should be fixed prior to 2.1 being released. How-To-Repeat: As root mount a CD-ROM. I used the 2.0.5 Install CD. # mount -t cd9660 /dev/cd-of-your-choice /mnt # (This may have been done automatically when the system booted.) Now, login on a second terminal as a plain user: login: user1 Password: % pwd /usr/user1 % gunzip /mnt/packages/All/lynx-2.3.7.tgz (escapes may be used for filename completion) You get the non-helpful message: /mnt/packages/All/lynz-2.3.7.tgz: Operation not supported (Mental note: We need to add error codes for "Write Protected" and one for "Not Ready", instead of using "Not Configured" or "Not Supported" for these legitimate events.) Back to the issue at hand. % Now, realizing the error, type this: % cp /mnt/packages/All/ly<ESCAPE> The process is now hung. On the root screen, do a ps -alx and see: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND ... 1000 133 1 0 -14 0 488 360 isoilk Ds+ v2 0:01.47 -csh (csh) ... Naturally a kill -9 has no effect. A reboot is required. Any other process (including remote FTP) that attempts to touch ISO filesystems after this point also hangs. A related "attack" is to ftp the site remotely and attempt to PUT something in a directory on a CD-ROM. The system could probably be put in this hung state by a non-account-holder using anonymous FTP as well. Anonymous FTP sites with any of the accessible data on CD-ROMs should be aware of this issue.
As uhclem%nemesis@fw.ast.com wrote: > > On the root screen, do a ps -alx and see: > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > ... > 1000 133 1 0 -14 0 488 360 isoilk Ds+ v2 0:01.47 -csh One of my /etc/daily jobs recently kept hanging on the same condition. It happened after booting a new kernel just the other day. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
>Now, login on a second terminal as a plain user: > login: user1 > Password: > % pwd > /usr/user1 > % gunzip /mnt/packages/All/lynx-2.3.7.tgz > (escapes may be used for filename completion) > You get the non-helpful message: > /mnt/packages/All/lynz-2.3.7.tgz: Operation not supported gzip should print which operation it tried. > (Mental note: We need to add error codes for "Write Protected" and > one for "Not Ready", instead of using "Not Configured" or "Not > Supported" for these legitimate events.) cd9660 uses cd9660_enotsupp() for all operations that it doesn't support, including for link and rename, which must be cleaned up by calling VOP_ABORTOP() and vput(). See msdosfs_abortop() for correct handling. ENODEV might be a better errno. EOPNOTSUPP only applies to networking according to the comment in errno.h :-). EROFS isn't quite right for file systems on devices that are inherently readonly. OTOH, cd9660 isn't inherently readonly. The current implementation just doesn't suppport writing, so EOPNOTSUPP is reasonable. If writing was supported then EROFS would be the natural errno. Bruce
State Changed From-To: open->closed The cd9660 filesystem wasn't checking for read-onlyness in several cases. This has been fixed and the fixes were brought into the 2.1 branch.