kern/98064: Crash with FIFOs (named pipes) and truncate()

[Bruce Evans]

The following reply was made to PR kern/98064; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Maxim Konovalov <maxim at macomnet.ru>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate()
Date: Tue, 30 May 2006 00:04:23 +1000 (EST)

 On Mon, 29 May 2006, Maxim Konovalov wrote:
 
 >>  I have used used the following fixes in this area for many years.  They
 >>  make truncate() on a fifo and some other file types always succeed
 >>  instead of wandering off into UFS_TRUNCATE() (which is always (?)
 >>  ffs_truncate()) and tending to cause panics there.
 > [...]
 >
 > Why doesn't RELENG_4 suffer from this?  The code of ufs_setattr() is
 > very similar there.
 
 Hmm, my fixes are for ~5.2 and they may be unnecessary there too.  I don't
 remember noticing this particular problem.  Perhaps some changes in -current
 resulted in ffs_update() doing more and happening to do something bad.
 Unfortunately, the PR doesn't contain much debugging info so it isn't
 clear that the problem is in ffs_update().
 
 I just found another problem.  ffs_truncate() panics for read-only file
 systems.  The unpatched ufs_setattr() only returns early for read-only
 file systems in the VREG, VLNK and VDIR cases.  So ffs_truncate() on a
 fifo on a read-only file system can apparently very easily panic.
 
 The panic in ffs_truncate() is strangely placed after doing some things,
 both null things and things that attempt to write to the file system.
 These things are mainly:
 
 - handling extended attributes.  I don't understand the details.
 - the !IO_NORMAL case (whatever that is).  Returns success without checking
    for read-only.
 - new size too large.  Returns failure early.
 - a subcase of the VLNK case.  Attempts to write even to read-only file
    systems.  Such writes are handled bogusly at lower levels and hopefully
    don't reach the disks (I use printfs to detect these and others.  Most
    involve setting file times for read-only file systems or directives
    to set file times that aren't handled properly on changing from rw
    to ro.  Here there is a file size change so not writing to disk might
    cause more serious problems).  Returns early.  In my previous reply
    I said that the VLNK case is unreachable and it panics if DIAGNOSTIC
    is configured.  Actually, only a subcase of the subcase panics.
 - null truncates (ones which don't change the size).  These are not quite
    null.  They attempt to set the file times even for read-only file
    systems.  Such writes are handled bogusly as above.  Returns early.
 
 If ffs_update() gets through these things without returning, it always
 panics in the read-only case.  The test program truncates to a nonzero
 length, presumably to get past the null truncate case, and its panic
 is not for the read-only case so it must be getting past the panic for
 that too.
 
 Bruce