[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

race reading /proc/mounts causes umount failure and potential for serious dataloss



clone 593516 -1
reassign -1 linux-2.6
retitle -1 linux-2.6: race reading /proc/mounts causes umount failure and potential for serious dataloss
severity -1 serious
thanks

Hi kernel team,

This bug was originally reported as #593516.  The schroot program
reads /proc/mounts to determine which filesystems to umount as it
cleans up after itself.  However, if more that one instance is running
then if one process reads /proc/mounts while another instance is
umounting filesystems then things get a bit screwy: the reader can
miss mount entries and as a result could purge entire filesystems
under the mistaken assumption that they are no longer mounted.

This is not specific to schroot: the problem could occur if any
process is mounting/umounting filesystems as another is reading
/proc/mounts.

In the case of schroot, we use /proc/mounts to umount all filesystems
under a given path prior to running "rm -r" on that path, so there's
the potential for serious dataloss if an entry in /proc/mounts gets
skipped as a result of this issue.  Since we examine the contents of
/proc/mounts as a sanity-check, and /proc/mounts is unreliable, it
means that our sanity-checking is equally unreliable...

I'm not aware of the specifics of how /proc/mounts is implemented, but
I think this could be made reliable if the contents were not changed
once opened (i.e. each reader gets a unique immutable copy rather than
a mutable global copy that's subject to spurious changes).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature


Reply to: