Re: kern/43963: libsa cd9660.c pathname lookup problem

[Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>]

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

From: Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: minoura%smtp.minoura.org@localhost, kern-bug-people%netbsd.org@localhost, 
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/43963: libsa cd9660.c pathname lookup problem
Date: Tue, 12 Oct 2010 17:49:17 +0200

 Hi,
 
 >      cd9660_open() traverses the ISO9660 path table incorrectly,
 >      and fails to open files in subdirectories.
 >      I'm afraid the author misunderstood the order of the entries.
 >      Note it can open any files in the root directory successfully.
 
 No, that's not correct.  The author (yours truly) understood the order
 of the entries in the path table quite well.  It is mkisofs which is
 at fault here.
 
 You can check it yourself by looking at "6.9.1 Order of Path Table Records"
 in the ISO 9660 specification (to be found e.g. at
 http://www.ecma-international.org/publications/standards/Ecma-119.htm)
 There it says that the main criterion for the order is the level in the
 directory hierarchy, i.e. the list starts with all the entries at level
 1 (by definition only the root directory), then all the entries at level
 2 (all the entries in the root directory), then all entries at level 3
 and so on. The second criterion then specifies that the entries at some
 level are to be sorted according to the directory number of their parent
 directory.
 
 So the code is totally correct in terminating the search loop when finding
 a directory entry with a different parent directory identifier number.
 
 Now I'm (more or less) indifferent to lifting the insistance on correctly
 written 9660 filesystems (there is already another workaround in the kernel
 9660 implementation for incorrectly sorted directory entries in the main
 directory tree), however, in that case you should probably restart the
 search at the top of the path table after identifying a path component,
 in order to be even more tolerant to incorrectly formatted filesystems.
 
 Fixing mkisofs would be my preferred solution here (as the code in question
 is only used during boot, we don't have to support reading CDs from
 different sources anyway.)
 
 Ciao,
 Wolfgang
 -- 
 Wolfgang%Solfrank.net@localhost                          Wolfgang Solfrank