bin/124409: fsck(1) requires exact entry for mountpoints when executing / bug by design in getfsfile(3) in .../lib/libc/gen/fstab.c

[Garrett Cooper]

>Number:         124409
>Category:       bin
>Synopsis:       fsck(1) requires exact entry for mountpoints when executing / bug by design in getfsfile(3) in .../lib/libc/gen/fstab.c
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 09 08:30:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Garrett Cooper
>Release:        8-CURRENT
>Organization:
n/a
>Environment:
FreeBSD optimus 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Jun  6 01:36:23 PDT 2008     gcooper at optimus:/usr/obj/usr/src/sys/OPTIMUS  i386
>Description:
Originally thinking that I encountered a minor usage bug, where the following fails:

optimus# fsck /usr/
fsck: Could not determine filesystem type

Even though the following succeeds:

optimus# fsck /usr
** /dev/ad10s1e (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
70050 files, 1216169 used, 2713069 free (24693 frags, 336047 blocks, 0.6% fragmentation)

I started digging a bit deeper, only to discover that the problem lies with the fact that there was a corner case not covered in getfsfile(3)...

If specified value for name [the only argument that gets passed into getfsfile(3)] has slash in it and its corresponding entry does not, or vice versa, the function will return NULL as it searches for an exact match to the fstab(5) entry.

This isn't incredibly critical from what I can tell, as it only affects fsck, however, if someone screwed up some scripts which call fsck or fstab, this would become a possible high-risk issue as it would require in-person support to fix fsck issues on boot.

mount(1) for whatever reason isn't affected by this problem (I tried multiple cases to ensure that this was the case).

Also, the manpage for getfsfile(3) should be updated such that implementers are aware that using name == "none" will return the first entry, which may not be the node of interest in fstab. This is another bug-gish thing by design...

I'm going to discuss this on hackers@ a bit as I need to make sure that I'm not going to restrict the search space for the problem, such that functionality gets broken...
>How-To-Repeat:
fsck // # should be the same as `fsck /' =)
>Fix:
Coming soon pending discussion on hackers@

>Release-Note:
>Audit-Trail:
>Unformatted: