NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ptyfs and chroot environments

In article <>,
Taylor R Campbell  <> wrote:
>(I am not subscribed to this list, so please cc me in replies.)
>   Date: Thu, 1 Apr 2010 15:55:39 -0400
>   From:
>   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
>       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
>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

Excellent! Please file a bug report.


Home | Main Index | Thread Index | Old Index