kern/44658: spurious chroot escape warning

[Taylor R Campbell <campbell+netbsd%mumble.net@localhost>]

>Number:         44658
>Category:       kern
>Synopsis:       spurious chroot escape warning
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 01 15:40:00 +0000 2011
>Originator:     Taylor R Campbell <campbell+netbsd%mumble.net@localhost>
>Release:        NetBSD 5.99.47
>Organization:
>Environment:
System: NetBSD oberon.local 5.99.47 NetBSD 5.99.47 (RIAMONODEBUG) #31: Mon Feb 
28 05:14:15 UTC 2011 
riastradh@smalltalk.local:/home/riastradh/netbsd/current/obj/sys/arch/i386/compile/RIAMONODEBUG
 i386
Architecture: i386
Machine: i386
>Description:

        I have been observing chroot escape warnings under the
        following circumstances:

                Process A is chrooted in /chroot0, and has a cwd of
                /chroot0/chroot1/a/b.

                Process B is chrooted in /chroot/chroot1, and rmdirs
                /chroot0/chroot1/a/b and /chroot0/chroot1/a.

                When process A chdirs to .., the kernel warns that it
                has escaped its chroot.

        I believe the nested chroot and the pair of processes is a red
        herring, and that it is sufficient for process A to have a
        chroot of /chroot and a cwd of /chroot/a/b and to rmdir
        /chroot/a/b and chdir to .., but I haven't correctly tested
        this hypothesis.  The last time I tried, NetBSD helpfully
        alerted me to PR kern/44657.  Fortunately, bulk builds are
        reasonably happy to pick up approximately where they left off.

>How-To-Repeat:

        Carefully.

>Fix:

        I believe the problem is that lookup_once in vfs_lookup.c calls
        vn_isunder to decide whether to warn, and vn_isunder correctly
        ascertains that the process's cwd is not under the process's
        root, because it is not, in fact, under *any* root, having been
        deleted.  So if lookup_once suppressed the warning if the
        directory has a link count under 2, or, more expensively (and
        probably unnecessarily), checked vn_isunder(dp, rootvnode), I
        think the spurious warning would go away.