Re: ptyfs and chroot environments

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

(I am not subscribed to this list, so please cc me in replies.)

   Date: Thu, 1 Apr 2010 15:55:39 -0400
   From: gary%duzan.org@localhost

   Just a random idea: would a null mount of /dev/pts into the chroot
   work? (I don't have it set up at the moment to test it.)

Hmm...  I ought to have thought of that: pkg_comp already uses plenty
of null mounts.  To address the remarks about security: security isn't
an issue in this case; I want only to isolate accidental damage to the
file system -- I'm not worried about processes nefariously futzing
with ptys not belonging to them.

I just tried it, and although xterm successfully launches and accepts
keyboard input, as soon as I exit xterm, the kernel consistently
panics.  This kernel was built from HEAD as of a few days ago for
NetBSD/macppc.  Here's the ddb backtrace; let me know if you want my
dmesg output.

vrelel: missing VOP_CLOSE(): vnode @ 0x1f47c020, flags 
(0x800004<ISTTY,INACTNOW>)
        tag VT_PTYFS(24), type VCHR(4), usecount 1, writecount 0, holdcount 0
        freelisthd 0x0, mount 0xd57a2018, data 0xd02f3d00 lock 0x1f47c0cc 
recursecnt 0
        tag VT_PTYFS, type 0, pty 4
panic: kernel diagnostic assertion "sn->sn_opencnt == 0" failed: file 
"/Users/riastradh/os/netbsd/current/src/sys/miscfs/specfs/spec_vnops.c", line 
321
cpu0: Begin traceback...
0xd593bcd0: at kern_assert+0x4c
0xd593bce0: at spec_node_destroy+0x1cc
0xd593bd00: at vrelel+0x698
0xd593bd40: at vrevoke+0x298
0xd593bd90: at genfs_revoke+0x1c
0xd593bda0: at layer_bypass+0x11c
0xd593be20: at VOP_REVOKE+0x44
0xd593be40: at exit1+0x524
0xd593bec0: at sys_exit+0x54
0xd593bee0: at syscall_plain+0x218
0xd593bf40: user SC trap #1 by 0xeff725cc: srr1=0xd032
            r1=0xffffd330 cr=0x28000042 xer=0 ctr=0xeff725c4
cpu0: End traceback...
dumpsys: TBD
rebooting