NetBSD Problem Report #46979

From apb@apb.cequrux.com  Tue Sep 18 11:47:08 2012
Return-Path: <apb@apb.cequrux.com>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 7C25263B907
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 18 Sep 2012 11:47:08 +0000 (UTC)
Message-Id: <20120918114703.D0C1E3B67C1@apb-laptoy.apb.alt.za>
Date: Tue, 18 Sep 2012 11:47:03 +0000 (UTC)
From: apb@cequrux.com
To: gnats-bugs@gnats.NetBSD.org
Subject: mount_ptyfs should not need "-o chroot" or "-c" flag
X-Send-Pr-Version: 3.95

>Number:         46979
>Category:       kern
>Synopsis:       mount_ptyfs should not need "-o chroot" or "-c" flag
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 18 11:50:00 +0000 2012
>Last-Modified:  Tue Sep 18 17:25:01 +0000 2012
>Originator:     Alan Barrett
>Release:        NetBSD 6.99.11
>Organization:
Not much
>Environment:
System: NetBSD 6.99.11 i386
Architecture: i386
Machine: i386
>Description:
If you are inside a chroot (say "/chrootdir"), and you mount a ptyfs
file system on /dev/pts inside your chroot, then ioctl(TIOCPTSNAME) is
likely to fail with ENOSPC.

What happens is: the ioctl handler calls pty_fill_ptmget(), which
calls (*ptm->makename), which is actually ptyfs__makename if ptyfs is
mounted.  ptyfs__makename calls ptyfs__getpath, which returns something
like "/chrootdir/dev/pts".  Then ptyfs__makename attempts to construct
a result like "/chrootdir/dev/pts/123", which does not fit in the
16-character space in struct ptmget, so it fails with ENOSPC.

Obviously it would be better to return "/dev/pts/123", which is what
the caller probably wanted (being a path name relative to the caller's
chroot directory), and which does fit in the available space.

ptyfs__getpath can do exactly that, but it does so only if the
PTYFSMNT_CHROOT flag is set.  This flag is set if mount_ptyfs(8) passed
the ALTF_CHROOT flag to mount(2).  That happens if mount_ptyfs was
invoked with the "-c" or "-o chroot" options.

So, if the chroot flag was set at mount time, then ptyfs__getpath works,
ptyfs__getname works, and ioctl(TIOCPTSNAME) works.  If the option was
not set at mount time, then things fail with ENOSPC.

>How-To-Repeat:
	See above.

>Fix:
	Fix: Make ptyfs__getname behave as if PTYFSMNT_CHROOT is always set.

	Workaround: Always specify "-o chroot" when invoking mount_ptyfs,
	unless you can be sure you are not inside a chroot.

>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46979: mount_ptyfs should not need "-o chroot" or "-c" flag
Date: Tue, 18 Sep 2012 18:16:22 +0100

 On Tue, Sep 18, 2012 at 11:50:00AM +0000, apb@cequrux.com wrote:
 > >Number:         46979
 > >Category:       kern
 > >Synopsis:       mount_ptyfs should not need "-o chroot" or "-c" flag
 ...
 > If you are inside a chroot (say "/chrootdir"), and you mount a ptyfs
 > file system on /dev/pts inside your chroot, then ioctl(TIOCPTSNAME) is
 > likely to fail with ENOSPC.

 Maybe the code should look to see if the current process is inside
 a/the chroot and then return a chroot relative path.

 	David

 -- 
 David Laight: david@l8s.co.uk

Home	PR Database Search