NetBSD Problem Report #47748

From www@NetBSD.org  Thu Apr 18 07:40:12 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id BA9DE63F427
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Apr 2013 07:40:11 +0000 (UTC)
Message-Id: <20130418074011.2493563F427@www.NetBSD.org>
Date: Thu, 18 Apr 2013 07:40:10 +0000 (UTC)
From: frederic@fauberteau.org
Reply-To: frederic@fauberteau.org
To: gnats-bugs@NetBSD.org
Subject: Invalid file on ffs
X-Send-Pr-Version: www-1.0

>Number:         47748
>Category:       kern
>Synopsis:       Invalid file on ffs
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 18 07:45:01 +0000 2013
>Closed-Date:    Thu Sep 26 07:54:32 +0000 2019
>Last-Modified:  Thu Sep 26 07:54:32 +0000 2019
>Originator:     Frédéric Fauberteau
>Release:        netbsd-6
>Organization:
>Environment:
NetBSD trashware 6.0_STABLE NetBSD 6.0_STABLE (TRASHWARE) #0: Fri Feb  8 09:00:00 CET 2013  root@trashware:/usr/obj/sys/arch/amd64/compile/TRASHWARE amd64
>Description:
An invalid file is in the directory tree and can not be removed.

The report of daily insecurity script is:
Checking setuid files and devices:
Setuid/device find errors:
find: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
find: fts_read: No such file or directory

When I use autocomplete to try to remove the file, I obtain:
root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory

root@trashware:pkg$ rm -rf /usr/pkgsrc/ham/tfkiss/pkg/CVS/
rm: CVS: Directory not empty
>How-To-Repeat:
No repeatable...

The file has probably been created by a failed ^C during a cvs update. The 'F' key is very closed to the 'C' key, but I don't know the exact combination.
>Fix:

>Release-Note:

>Audit-Trail:
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/47748: Invalid file on ffs
Date: Thu, 18 Apr 2013 10:57:59 +0200

 On Thu, 18 Apr 2013 07:45:01 +0000 (UTC), frederic@fauberteau.org wrote:
 > root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
 > rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory

 You could 'ls -li' the file, note the inode, then "shutdown now" to 
 single user mode, umount(8) the file system, clri(8) the inode, then 
 fsck(8) -fp the file system, and reboot. 

 HTH,
 hauke

From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <frederic@fauberteau.org>
To: <gnats-bugs@netbsd.org>
Cc: <kern-bug-people@netbsd.org>, <gnats-admin@netbsd.org>,
 <netbsd-bugs@netbsd.org>
Subject: Re: kern/47748: Invalid file on ffs
Date: Thu, 18 Apr 2013 12:24:09 +0200

 Le 2013-04-18 11:05, Hauke Fath a écrit :
 > The following reply was made to PR kern/47748; it has been noted by 
 > GNATS.
 >
 > From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: kern/47748: Invalid file on ffs
 > Date: Thu, 18 Apr 2013 10:57:59 +0200
 >
 >  On Thu, 18 Apr 2013 07:45:01 +0000 (UTC), frederic@fauberteau.org 
 > wrote:
 >  > root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
 >  > rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
 >
 >  You could 'ls -li' the file, note the inode, then "shutdown now" to
 >  single user mode, umount(8) the file system, clri(8) the inode, then
 >  fsck(8) -fp the file system, and reboot.
 >
 >  HTH,
 >  hauke

 I could not 'ls -li' the file since syscalls failed on it. But I should 
 try a fsck in single user mode before submitting PR. It does not 
 enlighten me on what was the problem with this file but it corrects the 
 fs.

 Sorry for the PR and thanks a lot,
 -- 
 Frédéric Fauberteau

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/47748: Invalid file on ffs
Date: Thu, 18 Apr 2013 09:45:44 -0400

 On Apr 18,  7:45am, frederic@fauberteau.org (frederic@fauberteau.org) wrote:
 -- Subject: kern/47748: Invalid file on ffs

 | >Number:         47748
 | >Category:       kern
 | >Synopsis:       Invalid file on ffs
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       high
 | >Responsible:    kern-bug-people
 | >State:          open
 | >Class:          sw-bug
 | >Submitter-Id:   net
 | >Arrival-Date:   Thu Apr 18 07:45:01 +0000 2013
 | >Originator:     Frédéric Fauberteau
 | >Release:        netbsd-6
 | >Organization:
 | >Environment:
 | NetBSD trashware 6.0_STABLE NetBSD 6.0_STABLE (TRASHWARE) #0: Fri Feb  8 09:00:00 CET 2013  root@trashware:/usr/obj/sys/arch/amd64/compile/TRASHWARE amd64
 | >Description:
 | An invalid file is in the directory tree and can not be removed.
 | 
 | The report of daily insecurity script is:
 | Checking setuid files and devices:
 | Setuid/device find errors:
 | find: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
 | find: fts_read: No such file or directory
 | 
 | When I use autocomplete to try to remove the file, I obtain:
 | root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
 | rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
 | 
 | root@trashware:pkg$ rm -rf /usr/pkgsrc/ham/tfkiss/pkg/CVS/
 | rm: CVS: Directory not empty
 | >How-To-Repeat:
 | No repeatable...
 | 
 | The file has probably been created by a failed ^C during a cvs update. The 'F' key is very closed to the 'C' key, but I don't know the exact combination.

 fsck -f should be able to fix it, and if not there is always fsdb/clri

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/47748: Invalid file on ffs
Date: Fri, 19 Apr 2013 06:12:54 +0000

 On Thu, Apr 18, 2013 at 10:30:11AM +0000, Fr?d?ric Fauberteau wrote:
  >  >  > root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
  >  >  > rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
  >  >
  >  >  You could 'ls -li' the file, note the inode, then "shutdown now" to
  >  >  single user mode, umount(8) the file system, clri(8) the inode, then
  >  >  fsck(8) -fp the file system, and reboot.
  >  
  >  I could not 'ls -li' the file since syscalls failed on it. But I should 
  >  try a fsck in single user mode before submitting PR. It does not 
  >  enlighten me on what was the problem with this file but it corrects the 
  >  fs.

 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
 such a file, because a string with a zero byte as the fourth character
 is three characters long; you have to have fsck remove it.

 (Without the zero byte, you'd probably have been able to name the file
 with autocompletion, and ls -l would have worked. Although I remember
 once a long time ago accidentally getting a file with a newline in its
 name, which turned out to be surprisingly hard to get rid of. I think
 I ended up needing to write a C program that called unlink(2).)

 It looks like CVS has some error path that creates control files using
 an uninitialized pathname. This is a bug in CVS, and I'd leave the PR
 open to remember it, except that there's zero chance we'll ever track
 it down.

 -- 
 David A. Holland
 dholland@netbsd.org

From: jnemeth@victoria.tc.ca (John Nemeth)
To: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, frederic@fauberteau.org
Cc: 
Subject: Re: kern/47748: Invalid file on ffs
Date: Sun, 21 Apr 2013 16:40:02 -0700

 On Aug 4,  6:22pm, David Holland wrote:
 }
 } The following reply was made to PR kern/47748; it has been noted by GNATS.
 } 
 } From: David Holland <dholland-bugs@netbsd.org>
 } To: gnats-bugs@NetBSD.org
 } Date: Fri, 19 Apr 2013 06:12:54 +0000
 } 
 }  On Thu, Apr 18, 2013 at 10:30:11AM +0000, Fr?d?ric Fauberteau wrote:
 }   >  >  > root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
 }   >  >  > rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
 }   >  >
 }   >  >  You could 'ls -li' the file, note the inode, then "shutdown now" to
 }   >  >  single user mode, umount(8) the file system, clri(8) the inode, then
 }   >  >  fsck(8) -fp the file system, and reboot.
 }   >  
 }   >  I could not 'ls -li' the file since syscalls failed on it. But I should 
 }   >  try a fsck in single user mode before submitting PR. It does not 
 }   >  enlighten me on what was the problem with this file but it corrects the 
 }   >  fs.
 }  
 }  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.

 }  (Without the zero byte, you'd probably have been able to name the file
 }  with autocompletion, and ls -l would have worked. Although I remember
 }  once a long time ago accidentally getting a file with a newline in its
 }  name, which turned out to be surprisingly hard to get rid of. I think
 }  I ended up needing to write a C program that called unlink(2).)

      I had a situation once where a filename had a "/" in it.  Under
 normal conditions this would be impossible.  The situation arose as the
 machine was an NFS server, and the client was a Mac.  MacOS used ":" as
 a path seperator, so a "/" had no special meaning to it.  My solution
 was to clri and fsck as somebody else suggested.  This happened around
 1992 give or take a year.  I would hope that this wouldn't be able to
 happen with a modern system.  I don't recall which machine it was on
 now, but the server was running either SunOS 4.x or Ultrix 3/4 (VAX).

 }-- End of excerpt from David Holland

From: David Laight <david@l8s.co.uk>
To: John Nemeth <jnemeth@victoria.tc.ca>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/47748: Invalid file on ffs
Date: Mon, 22 Apr 2013 22:29:01 +0100

 On Sun, Apr 21, 2013 at 04:40:02PM -0700, John Nemeth wrote:
 > 
 >      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.

 I remember getting one a 0 byte in the middle of the filename on
 a SYSV filesystem (fixed length names).
 Was impossible to get a match, probably because the kernel was matching
 all the bytes.

 Probably happened due to a randmon kernel overwrite getting paged out.
 (We would have been testing device drivers on that system.)

 	David

 -- 
 David Laight: david@l8s.co.uk

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, frederic@fauberteau.org
Subject: Re: kern/47748: Invalid file on ffs
Date: Fri, 24 May 2013 08:15:30 +0000

 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.

 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.

 But if the filename merely contained a control character, fsck
 wouldn't have removed it. Or so I'd think anyway. All I see in
 fsck_ffs is checks for embedded 0 and '/'.

 -- 
 David A. Holland
 dholland@netbsd.org

From: jnemeth@victoria.tc.ca (John Nemeth)
To: David Holland <dholland-bugs@NetBSD.org>, gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        frederic@fauberteau.org
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

State-Changed-From-To: open->closed
State-Changed-By: triaxx@NetBSD.org
State-Changed-When: Thu, 26 Sep 2019 07:54:32 +0000
State-Changed-Why:
I don't remember the context in which this problem occurs, it is clearly not reproducible, the machine does not run anymore and netbsd-6 is no longer maintained.


>Unformatted:

Home	PR Database Search