lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081021153105.GD15685@mit.edu>
Date:	Tue, 21 Oct 2008 11:31:05 -0400
From:	Theodore Tso <tytso@....edu>
To:	Rogério Brito <rbrito@....usp.br>
Cc:	Alexandre Lymberopoulos <lymber@...il.com>, 502583@...s.debian.org,
	502583-submitter@...s.debian.org, linux-kernel@...r.kernel.org,
	rafael@...ian.org
Subject: Re: Bug#502583: scary messages in dmesg

On Tue, Oct 21, 2008 at 12:35:00PM -0200, Rogério Brito wrote:
> > I don't know if you would call it a bug or not.  Fundamentally,
> > yanking out a USB stick without unmounting it first is dangerous, and
> > can lead to data loss.
> 
> At least sync'ing...

I'm loath to suggest "just syncing", because if there is some program
still writing to the USB stick (example: you fire up openoffice and
ask it to "export to PDF".  That command returns instantly, and the
PDF export happens in the background --- as you will discover if you
try to exit OpenOffice.  Well, if a user doesn't try to exit
OpenOffice, and just uses the "sync" command, they could still end up
trashing data.

Also note that for older flash drives, pulling the power while it is
writing could potentially lead to corruption of the USB stick's flash
translation layer (FTL), which could cause the device to become
totally non-functional.  It's for that reason that one particular
Digital SLR's stop writing to the compact flash card the instant the
access door to the flash card is opened, throwing away all of the last
7-8 pictures in the digital camera's write buffer.  I'm assuming they
did this because some users ejected the flash card while it was
writing leading to loss of the flash card plus *all* of the pictures
on the flash card, and they decided the risk of having a Very Unhappy
User was worth the tradeoff of throwing away only the recently taken
photographs that hadn't made it onto the card yet.

If you have a USB stick that has a flashing light to indicate write
activity, and you type the "sync" command, and you wait for the
flashing light to stop, and you *know* nothing else might be trying to
write to the device, sure it might be safe to eject.  But if we have a
command-line user who knows enough to type "sync" into a command-line
shell, wouldn't it be better to create a setuid shell command, call it
something like "usbeject" which finds any USB storage device that was
auto-mounted (i.e., not mounted manually by the user or via an
/etc/fstab entry), and if there is only one such devices,
automatically tries to unmount it?  If there is more than one such
device, it should ask the user (or maybe use lsof to see if there is
only one that appears not to be in use), and if it fails, it should
print a huge warning message as well as the output of "lsof" so the
user knows which program(s) to close before unmounting the device.

Solving this problem for desktop users is harder; probably the best
thing you can do is to throw up "shame" dialog box telling them that
they did Something Wrong, and while they may have gotten lucky this
time, that next time they should close all programs using the USB
storage device, and then right-click on the mounted disk icon and
select "eject".  That's what Windows does, and IIRC, what Mac OS X
does; there really isn't much else that can be done.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ