d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

MFC r196508:

Browse Source 
Our implementation of granpt(3) could be valid in the future.

  When I wrote the pseudo-terminal driver for the MPSAFE TTY code, Robert
  Watson and I agreed the best way to implement this, would be to let
  posix_openpt() create a pseudo-terminal with proper permissions in place
  and let grantpt() and unlockpt() be no-ops.

  This isn't valid behaviour when looking at the spec. Because I thought
  it was an elegant solution, I filed a bug report at the Austin Group
  about this. In their last teleconference, they agreed on this subject.
  This means that future revisions of POSIX may allow grantpt() and
  unlockpt() to be no-ops if an open() on /dev/ptmx (if the implementation
  has such a device) and posix_openpt() already do the right thing.

  I'd rather put this in the manpage, because simply mentioning we don't
  comply to any standard makes it look worse than it is. Right now we
  don't, but at least we took care of it.

  Approved by:  re (kib)
This commit is contained in:
Ed Schouten 2009-08-28 10:25:26 +00:00
parent 4bff593a8c
commit 2025af696e
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/stable/8/; revision=196614
1 changed files with 11 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
lib/libc/stdlib/ptsname.3
View File

@ -134,14 +134,22 @@ The slave pseudo-terminal device could not be accessed.
The
.Fn ptsname
function conforms to
.St -p1003.1-2001 .
.St -p1003.1-2008 .
.Pp
This implementation of
.Fn grantpt
and
.Fn unlockpt
does not comply with any standard, because these functions assume the
pseudo-terminal has the correct attributes upon creation.
does not conform to
.St -p1003.1-2008 ,
because it depends on
.Xr posix_openpt 2
to create the pseudo-terminal device with proper permissions in place.
It only validates whether
.Fa fildes
is a valid pseudo-terminal master device.
Future revisions of the specification will likely allow this behaviour,
as stated by the Austin Group.
.Sh HISTORY
The
.Fn grantpt ,
@ -150,15 +158,3 @@ and
.Fn unlockpt
functions appeared in
.Fx 5.0 .
.Sh NOTES
The purpose of the
.Fn grantpt
and
.Fn unlockpt
functions has no meaning in
.Fx ,
because pseudo-terminals obtained by
.Xr posix_openpt 2
are created on demand.
Because these devices are created with proper permissions in place, they
are guaranteed to be unused by unprivileged processes.