NetBSD Problem Report #56936
From www@netbsd.org Fri Jul 22 11:15:18 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 8A6EC1A923C
for <gnats-bugs@gnats.NetBSD.org>; Fri, 22 Jul 2022 11:15:18 +0000 (UTC)
Message-Id: <20220722111516.8C6B11A923D@mollari.NetBSD.org>
Date: Fri, 22 Jul 2022 11:15:16 +0000 (UTC)
From: rokuyama.rk@gmail.com
Reply-To: rokuyama.rk@gmail.com
To: gnats-bugs@NetBSD.org
Subject: posix_openpt(O_RDWR | O_NOCTTY) fails when configuring pkgsrc/x11/mlterm
X-Send-Pr-Version: www-1.0
>Number: 56936
>Category: pkg
>Synopsis: posix_openpt(O_RDWR | O_NOCTTY) fails when configuring pkgsrc/x11/mlterm
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: gutteridge
>State: analyzed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jul 22 11:20:00 +0000 2022
>Closed-Date:
>Last-Modified: Wed Sep 14 03:55:02 +0000 2022
>Originator: Rin Okuyama
>Release: 9.0, 9.2 (?)
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD nb9 9.2 NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
pkgsrc/x11/mlterm tries to detect whether system has working
posix_openpt(3) as:
mlterm-3.9.2/baselib/configure:
----
...
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include <fcntl.h>
int
main ()
{
return posix_openpt(O_RDWR | O_NOCTTY) == -1;
;
return 0;
}
_ACEOF
if ac_fn_c_try_run "$LINENO"; then :
...
----
This is expected to pass for NetBSD, but it does not for some cases.
For official package build of pkgsrc-2022Q[12] and -2021Q4 for amd64,
i386, and aarch64 (for 9.0), this test failed and configure fell back
to old BSD pty.
Also, there is report on netbsd-users@, in which x11/mlterm is
misconfigured for NetBSD/amd64 9.2:
https://mail-index.netbsd.org/netbsd-users/2022/07/21/msg028733.html
On the other hand, for pkgsrc-current for NetBSD/amd64 9.0:
http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/.9.0-current-2022-07-15-22.09-being-update/All/mlterm-3.9.2nb3.tgz
this test succeeded, and mlterm uses posix_openpt(3) appropriately.
Also, I could not reproduce the problem by myself for freshly-installed
NetBSD/amd64 9.2:
- Manually compiled conftest.c above passes as expected.
- x11/mlterm from pkgsrc-2022Q2 is successfully configured to use
posix_openpt(3).
>How-To-Repeat:
N/A
>Fix:
N/A
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Fri, 22 Jul 2022 22:37:44 +0000
On Fri, Jul 22, 2022 at 11:20:01AM +0000, rokuyama.rk@gmail.com wrote:
> For official package build of pkgsrc-2022Q[12] and -2021Q4 for amd64,
> i386, and aarch64 (for 9.0), this test failed and configure fell back
> to old BSD pty.
>
> Also, there is report on netbsd-users@, in which x11/mlterm is
> misconfigured for NetBSD/amd64 9.2:
>
> https://mail-index.netbsd.org/netbsd-users/2022/07/21/msg028733.html
>
> On the other hand, for pkgsrc-current for NetBSD/amd64 9.0:
>
> http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/.9.0-current-2022-07-15-22.09-being-update/All/mlterm-3.9.2nb3.tgz
>
> this test succeeded, and mlterm uses posix_openpt(3) appropriately.
>
> Also, I could not reproduce the problem by myself for freshly-installed
> NetBSD/amd64 9.2:
>
> - Manually compiled conftest.c above passes as expected.
> - x11/mlterm from pkgsrc-2022Q2 is successfully configured to use
> posix_openpt(3).
Someone needs to check config.log from a machine where it failed to
see what the error message is.
It's almost certainly something silly.
--
David A. Holland
dholland@netbsd.org
From: "David H. Gutteridge" <david@gutteridge.ca>
To: Gnats Bugs <gnats-bugs@netbsd.org>, dholland@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Tue, 06 Sep 2022 18:29:00 -0400
On Fri, Jul 22, 2022 at 11:20:01AM +0000, rokuyama.rk@gmail.com wrote:
> For official package build of pkgsrc-2022Q[12] and -2021Q4 for amd64,
> i386, and aarch64 (for 9.0), this test failed and configure fell back
> to old BSD pty.
>
> Also, there is report on netbsd-users@, in which x11/mlterm is
> misconfigured for NetBSD/amd64 9.2:
>
> https://mail-index.netbsd.org/netbsd-users/2022/07/21/msg028733.html
>
> On the other hand, for pkgsrc-current for NetBSD/amd64 9.0:
>
> http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/.9.0-current-2022-07-15-22.09-being-update/All/mlterm-3.9.2nb3.tgz
>
> this test succeeded, and mlterm uses posix_openpt(3) appropriately.
>
> Also, I could not reproduce the problem by myself for freshly-installed
> NetBSD/amd64 9.2:
>
> - Manually compiled conftest.c above passes as expected.
> - x11/mlterm from pkgsrc-2022Q2 is successfully configured to use
> posix_openpt(3).
The cause of the issue is that the package uses AC_RUN_IFELSE to check
if the posix_openpt(3) call *succeeds at runtime[1]*, not just if it
compiles and links. If the build environment is sandboxed, then the
call to open /dev/ptmx will fail, and the package will fall back to the
old "bsd" implementation instead.
The fix would be to remove the runtime check in the configure script,
if we want it reliably building in official (presumably sandboxed)
builds. I've had to do that in the past for other packages that did
something similar.
1. See baselib/configure.in starting at line 279
Dave
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Tue, 6 Sep 2022 22:45:05 +0000
On Tue, Sep 06, 2022 at 10:30:03PM +0000, David H. Gutteridge wrote:
> The cause of the issue is that the package uses AC_RUN_IFELSE to check
> if the posix_openpt(3) call *succeeds at runtime[1]*, not just if it
> compiles and links. If the build environment is sandboxed, then the
> call to open /dev/ptmx will fail, and the package will fall back to the
> old "bsd" implementation instead.
Ugh.
On the one hand, it's good for configure tests to check that things
actually work, because sometimes they don't. On the other hand, it's
annoying in cases like this.
> The fix would be to remove the runtime check in the configure script,
> if we want it reliably building in official (presumably sandboxed)
> builds. I've had to do that in the past for other packages that did
> something similar.
CONFIGURE_ENV+=ac_cv_mumble=yes if NetBSD is the most expedient way.
Problem is, I suspect even now not everyone uses ptyfs.
What does it fall back to? openpty(3) ought to work correctly whether
or not ptyfs is present. (And why doesn't posix_openpt?)
--
David A. Holland
dholland@netbsd.org
From: "David H. Gutteridge" <david@gutteridge.ca>
To: Gnats Bugs <gnats-bugs@netbsd.org>, dholland-pbugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when configuring
pkgsrc/x11/mlterm
Date: Wed, 07 Sep 2022 17:33:46 -0400
On Tue, 6 Sep 2022 at 22:50:02 +0000 (UTC), David Holland wrote:
> CONFIGURE_ENV+=ac_cv_mumble=yes if NetBSD is the most expedient way.
It seems "CONFIGURE_ENV+= bl_cv_pty=streams" was already tried:
http://mail-index.netbsd.org/netbsd-users/2022/07/22/msg028743.html
I don't follow why it was reported as not working, as it worked for me
in my sandboxed environment. (I see now the reporter was using a
sandbox, too.) With that, I end up with mlterm using posix_openpt(3).
> What does it fall back to? openpty(3) ought to work correctly whether
> or not ptyfs is present. (And why doesn't posix_openpt?)
It falls back to its own home-rolled "open_pty" function, which
ultimately does
if ((*master = open(name, O_RDWR, 0)) == -1)
following its own hard-coded list of "old-style" BSD ptys.
Inside a sandbox, I went as far as ktracing the posix_openpt(3) call,
which results in:
1963 1 open_test2 CALL open(0x400b7e,0,0x7f7fff5f3328)
1963 1 open_test2 NAMI "/dev/ptmx"
1963 1 open_test2 RET open -1 errno 45 Operation not supported
Inside a sandbox, openpty(3) also doesn't work, as I'd noticed since
script(1) fails to work in that context.
script: openpty: No such file or directory
22686 1 script CALL open(0x6fd6ee21228c,2,0)
22686 1 script NAMI "/dev/ptm"
22686 1 script RET open 4
22686 1 script CALL ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
22686 1 script RET ioctl -1 errno 45 Operation not supported
Dave
State-Changed-From-To: open->analyzed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Wed, 07 Sep 2022 21:49:34 +0000
State-Changed-Why:
Issue analyzed.
Responsible-Changed-From-To: pkg-manager->gutteridge
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Wed, 07 Sep 2022 21:51:17 +0000
Responsible-Changed-Why:
Take, since I've done the analysis.
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
rokuyama.rk@gmail.com
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Thu, 8 Sep 2022 00:55:33 +0200
Am Wed, Sep 07, 2022 at 09:35:01PM +0000 schrieb David H. Gutteridge:
> Inside a sandbox, openpty(3) also doesn't work, as I'd noticed since
> script(1) fails to work in that context.
>
> script: openpty: No such file or directory
>
> 22686 1 script CALL open(0x6fd6ee21228c,2,0)
> 22686 1 script NAMI "/dev/ptm"
> 22686 1 script RET open 4
> 22686 1 script CALL ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
> 22686 1 script RET ioctl -1 errno 45 Operation not supported
That means your sandbox is not configured correctly. Do you have
/dev/pts null-mounted in the chroot?
Joerg
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org, joerg@bec.de
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Wed, 07 Sep 2022 21:25:39 -0400
On Wed, 2022-09-07 at 23:00 +0000, Joerg Sonnenberger wrote:
> The following reply was made to PR pkg/56936; it has been noted by
> GNATS.
>=20
> From: Joerg Sonnenberger <joerg@bec.de>
> To: gnats-bugs@netbsd.org
> Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org,
> pkgsrc-bugs@netbsd.org,
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0rokuyama.rk@gmail.com
> Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
> =C2=A0configuring pkgsrc/x11/mlterm
> Date: Thu, 8 Sep 2022 00:55:33 +0200
>=20
> =C2=A0Am Wed, Sep 07, 2022 at 09:35:01PM +0000 schrieb David H. Gutteridg=
e:
> =C2=A0>=C2=A0 Inside a sandbox, openpty(3) also doesn't work, as I'd noti=
ced
> since
> =C2=A0>=C2=A0 script(1) fails to work in that context.
> =C2=A0>=C2=A0=20
> =C2=A0>=C2=A0 script: openpty: No such file or directory
> =C2=A0>=C2=A0=20
> =C2=A0>=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 script=C2=
=A0=C2=A0 CALL=C2=A0 open(0x6fd6ee21228c,2,0)
> =C2=A0>=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 script=C2=
=A0=C2=A0 NAMI=C2=A0 "/dev/ptm"
> =C2=A0>=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 script=C2=
=A0=C2=A0 RET=C2=A0=C2=A0 open 4
> =C2=A0>=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 script=C2=
=A0=C2=A0 CALL=C2=A0 ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
> =C2=A0>=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 script=C2=
=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1 errno 45 Operation not
> supported
> =C2=A0
> =C2=A0That means your sandbox is not configured correctly. Do you have
> =C2=A0/dev/pts null-mounted in the chroot?
> =C2=A0
> =C2=A0Joerg
>=20
No, I don't. I never even noticed any of this until I was trying to
diagnose this particular issue, my (limited) bulk builds always "just
worked" for me. (I don't use mlterm.)
My basis for defining the sandbox has always been essentially what
pkgtools/mksandbox does, which doesn't seem to cover this case (and I'm
guessing that's true for some other installations, or they follow some
other similar means of definition).
Dave
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: agc@NetBSD.org
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Thu, 8 Sep 2022 07:17:21 +0200
On Thu, Sep 08, 2022 at 12:55:33AM +0200, Joerg Sonnenberger wrote:
> Am Wed, Sep 07, 2022 at 09:35:01PM +0000 schrieb David H. Gutteridge:
> > Inside a sandbox, openpty(3) also doesn't work, as I'd noticed since
> > script(1) fails to work in that context.
> >
> > script: openpty: No such file or directory
> >
> > 22686 1 script CALL open(0x6fd6ee21228c,2,0)
> > 22686 1 script NAMI "/dev/ptm"
> > 22686 1 script RET open 4
> > 22686 1 script CALL ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
> > 22686 1 script RET ioctl -1 errno 45 Operation not supported
>
> That means your sandbox is not configured correctly. Do you have
> /dev/pts null-mounted in the chroot?
If that's a requirement, pkgtools/mksandbox should learn about it -
AFAICT it doesn't handle this.
Thomas
From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56936 CVS commit: pkgsrc/x11/mlterm
Date: Sat, 10 Sep 2022 00:14:19 +0000
Module Name: pkgsrc
Committed By: gutteridge
Date: Sat Sep 10 00:14:19 UTC 2022
Modified Files:
pkgsrc/x11/mlterm: Makefile
Log Message:
mlterm: force consistent builds with posix_openpt(3) on NetBSD
Work around the fact this package tests whether posix_openpt(3) works at
runtime. This fails in typical sandboxed build environments (including
TNF's used for official binary builds), which causes a fallback to use
"old-style" BSD ptys, which can result in runtime failures.
Addresses PR pkg/56936. Needs monitoring to ensure official TNF binary
packages now behave as expected.
To generate a diff of this commit:
cvs rdiff -u -r1.175 -r1.176 pkgsrc/x11/mlterm/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Sat, 10 Sep 2022 04:01:04 +0000
On Wed, Sep 07, 2022 at 11:00:03PM +0000, Joerg Sonnenberger wrote:
> > Inside a sandbox, openpty(3) also doesn't work, as I'd noticed since
> > script(1) fails to work in that context.
> >
> > script: openpty: No such file or directory
> >
> > 22686 1 script CALL open(0x6fd6ee21228c,2,0)
> > 22686 1 script NAMI "/dev/ptm"
> > 22686 1 script RET open 4
> > 22686 1 script CALL ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
> > 22686 1 script RET ioctl -1 errno 45 Operation not supported
>
> That means your sandbox is not configured correctly. Do you have
> /dev/pts null-mounted in the chroot?
Openpty falls back to opening pty devices, so it should work
regardless of whether /dev/pts is present. Unless you have no ptys at
all in the sandbox, and that does seem like a configuration error.
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Sat, 10 Sep 2022 04:05:25 +0000
also,
On Wed, Sep 07, 2022 at 09:35:01PM +0000, David H. Gutteridge wrote:
> > What does it fall back to? openpty(3) ought to work correctly whether
> > or not ptyfs is present. (And why doesn't posix_openpt?)
>
> It falls back to its own home-rolled "open_pty" function, which
> ultimately does
>
> if ((*master = open(name, O_RDWR, 0)) == -1)
>
> following its own hard-coded list of "old-style" BSD ptys.
Ugh. I mean, you need that code if you want to run everywhere, but it
ought to know about openpty().
(My question about posix_openpt stands, too.)
--
David A. Holland
dholland@netbsd.org
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org, dholland-pbugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Sun, 11 Sep 2022 17:11:51 -0400
On Sat, 2022-09-10 at 04:05 +0000, David Holland wrote:
> The following reply was made to PR pkg/56936; it has been noted by
> GNATS.
>=20
> From: David Holland <dholland-pbugs@netbsd.org>
> To: gnats-bugs@netbsd.org
> Cc:=20
> Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
> =C2=A0configuring pkgsrc/x11/mlterm
> Date: Sat, 10 Sep 2022 04:01:04 +0000
>=20
> =C2=A0On Wed, Sep 07, 2022 at 11:00:03PM +0000, Joerg Sonnenberger wrote:
> =C2=A0 >=C2=A0 >=C2=A0 Inside a sandbox, openpty(3) also doesn't work, as=
I'd noticed
> since
> =C2=A0 >=C2=A0 >=C2=A0 script(1) fails to work in that context.
> =C2=A0 >=C2=A0 >=C2=A0=20
> =C2=A0 >=C2=A0 >=C2=A0 script: openpty: No such file or directory
> =C2=A0 >=C2=A0 >=C2=A0=20
> =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =
script=C2=A0=C2=A0 CALL=C2=A0 open(0x6fd6ee21228c,2,0)
> =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =
script=C2=A0=C2=A0 NAMI=C2=A0 "/dev/ptm"
> =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =
script=C2=A0=C2=A0 RET=C2=A0=C2=A0 open 4
> =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =
script=C2=A0=C2=A0 CALL=C2=A0
> ioctl(4,TIOCPTMGET,0x7f7fffd49b00)
> =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0 22686=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =
script=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1 errno 45 Operation not
> supported
> =C2=A0 >=C2=A0=20
> =C2=A0 >=C2=A0 That means your sandbox is not configured correctly. Do yo=
u have
> =C2=A0 >=C2=A0 /dev/pts null-mounted in the chroot?
> =C2=A0
> =C2=A0Openpty falls back to opening pty devices, so it should work
> =C2=A0regardless of whether /dev/pts is present. Unless you have no ptys =
at
> =C2=A0all in the sandbox, and that does seem like a configuration error.
openpty(3) does fall back to trying to open pty devices, and fails like
so:
22686 1 script CALL open(0x7f7fffd496d5,2,0)
22686 1 script NAMI "/dev/ptyp0"
22686 1 script RET open -1 errno 2 No such file or directory
There are no pty devices in the sandboxes I have, because there are also
none under actual /dev. They are not populated in any installs I have,
presumably on purpose given it says in MAKEDEV "creating BSD style tty
nodes with ptyfs is a security issue"?
Dave
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56936: posix_openpt(O_RDWR | O_NOCTTY) fails when
configuring pkgsrc/x11/mlterm
Date: Wed, 14 Sep 2022 03:51:44 +0000
On Sun, Sep 11, 2022 at 09:15:02PM +0000, David H. Gutteridge wrote:
> openpty(3) does fall back to trying to open pty devices, and fails like
> so:
>
> 22686 1 script CALL open(0x7f7fffd496d5,2,0)
> 22686 1 script NAMI "/dev/ptyp0"
> 22686 1 script RET open -1 errno 2 No such file or directory
>
> There are no pty devices in the sandboxes I have, because there are also
> none under actual /dev. They are not populated in any installs I have,
> presumably on purpose given it says in MAKEDEV "creating BSD style tty
> nodes with ptyfs is a security issue"?
The security problem arises if you have both ptyfs and old-style pty
devices, because they are attached to the same internal objects but
have their own file permissions, which will then mostly be wrong.
Don't do that.
Having some ptys in the chroot that are the same as ptys you're using
outside isn't good either, but creating one that's high-enough
numbered that you won't use it elsewhere by accident is fine. So is
inserting a copy of ptyfs via null mount, though this makes all your
ordinary ptys accessible there so you need to be sure not to use the
same uids as outside.
However, having no ptys at all is bound to break some stuff, like,
apparently, mlterm. :-(
(And I still wonder about posix_openpt. If we intend to continue to
support old-style ptys, it's broken. If not, the old code in openpty
should probably be G/C'd. This is a matter for a different PR though.)
--
David A. Holland
dholland@netbsd.org
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2022
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home