Re: kern/47748: Invalid file on ffs

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

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

From: jnemeth%victoria.tc.ca@localhost (John Nemeth)
To: David Holland <dholland-bugs%NetBSD.org@localhost>, 
gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost,
        frederic%fauberteau.org@localhost
Subject: Re: kern/47748: Invalid file on ffs
Date: Sat, 25 May 2013 00:39:54 -0700

 On Oct 14,  2:51am, David Holland wrote:
 } On Sun, Apr 21, 2013 at 11:45:05PM +0000, John Nemeth wrote:
 }  >  }  It looks to me like it was probably four (or maybe more) characters
 }  >  }  long with a zero byte as the fourth character. There is no way to name
 }  >  
 }  >       Except that it should be impossible to create such a file no
 }  >  matter what an application does.  If a zero byte were to ever appear in
 }  >  a filename it would represent a serious bug in the filesystem code or
 }  >  memory corruption.
 } 
 } You'd think so, yes. On the other hand, clearly the file was created
 } from an uninitialized string or the name wouldn't have begun with
 } K+\x6.
 
      As far as the kernel is concerned, it shouldn't matter what the
 string contains, as it is just a "label" and the kernel doesn't
 interpret it.
 
 } Another possibility is that the next byte of the filename was one of
 } the magic values > 0x80 that sh's parser uses for internal signalling.
 } That would likely make it impossible to address the file from the
 } shell, with or without autocompletion. (If the shell was sh, anyway.)
 } I could also imagine 0xff confusing some shells, particularly csh.
 
      It may confuse the shell, but it shouldn't confuse the kernel.
 
      Basically, the kernel will get a pointer to some chunk of memory.
 Assuming the pointer is within the processes address space and isn't
 NULL, the kernel will use it.  It will scan the string looking for "/"
 which it will use a directory seperator, and it will also look for NIL
 which will terminate the string (assuming the string doesn't exceed the
 max length).  Pretty much all other characters are just part of a
 "label" and have no special significance (the labels "." and ".." do
 refer to current directory and parent directory respectively).  Given
 this, there should be no way for a NIL (or "/") to get into a filename
 on disk.
 
      As an aside, I did have a system once that managed to get a "/" in
 a filename on disk.  That was interesting.  The cause was that the
 system was acting as an NFS server for some Macs.  And, MacOS used ":"
 as a directory seperator, so "/" had no special meaning.  I ended up
 using clri to kill the inode, then let fsck clean up.  This was way
 back around 1990.
 
 } But if the filename merely contained a control character, fsck
 
      Although obnoxious and awkward to handle, it isn't a filesystem
 error.
 
 } wouldn't have removed it. Or so I'd think anyway. All I see in
 } fsck_ffs is checks for embedded 0 and '/'.
 
      Those are the only characters that aren't valid in filenames.
 
 }-- End of excerpt from David Holland