One should eject the zip disk to ensure Linux will recheck the mode
before eject ing it. I do not know if this is required, however here
is a patch for ziptool. c by Grant R. Guenther
(http://www.torque.net/ziptool.html). I dont know if it will work, i
could not verify it, my scsi zip drive is on another box, and the p pa
one does not want to work anymore for some reason (think the MB in the
box is
shot).
i dont see why one would want not to eject it, if they have a cron
script or som ething to that effect do it a intruded could then just
run the program and chang e mode''s w/o ejecting, this might be more
trouble than worth.
but here it is anyway.
btw, can someone let me know if this works... thanx.
here is the patch.
to apply it.. put it in the same directory as ziptool.c and simple type
patch < ziptool-noeject.patch (or whatever you saved the file as.
--Start--''ziptool-noeject.patch''--
--- ziptool.c.orig Mon Oct 13 22:49:38 1997
+++ ziptool.c Fri Oct 17 16:08:55 1997
@@ -195,7 +195,11 @@
dostatus(fd,dev);
- eject(fd); /* so linux can reset the wp mode */
+/* eject(fd); so linux can reset the wp mode
+ now it will not eject disk after mode change
+
+*/
+
}
void error(char * msg)
--End--
In accordance to prophecy Scott Kaplan wrote:
# Does anyone have any experience using a zip drive as a read-only
# medium for storing things like tripwire files, PGP signed keys and
# kernels? Is there a way to switch it to read/write mode without
# ejecting it?
[mod: Many people (including Jason) didn''t catch the essense of this
question. The question is: "when I change the read/write mode, my zip
disk always ejects the disk. So can I COUNT on it doing that? If
that''s the case, a hacker cannot hack my machine, change the
read/write status of my currently read-only zip disk, and update the
tripwire database for the changes he made to my system. If he makes an
attempt I would find the disk ejected in the morning, which should be
treated as a serious security breach. This would require the hardware
to do the "eject on status change", without possibility of override.
So the answer is "no, this is not safe".
In the above code segment, the "eject (fd)" should be replaced by
something that tells the kernel that the disk was changed. For an
example on how to do that I''d look into "fdformat". Between
formatting
and verifying it tells the kernel that the disk changed. My kernel
always reports "disk changed on [fd0]" at that point. Also thanks to
Adam Morris (Adam.Morris@onyx.net), who also noted the "eject" in
ziptools. He adds that the password protected write protect mode might
be usable in this case, assuming that the designers of the zip disk
are not complete fools (storing the password in a decryptable way on
an accessible part of the zip disk).
Matt Panzer (panzer@dhp.com) adds that ZIP disk encryption has been
broken, and that the read-only bit probably falls just as fast as the
encryption does. -- REW]
Jay.
----------------------------------
E-Mail: Jason Aras <jaras@exit3.com>
Date: 17-Oct-97
Time: 16:03:23
----------------------------------