The following issue has been REOPENED.
======================================================================
http://austingroupbugs.net/view.php?id=96
======================================================================
Reported By: EdSchouten
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 96
Category: System Interfaces
Type: Clarification Requested
Severity: Comment
Priority: normal
Status: Under Review
Name: Ed Schouten
Organization: The FreeBSD Project
User Reference:
Section: posix_openpt
Page Number: 0
Line Number: 0
Final Accepted Text:
======================================================================
Date Submitted: 2009-06-29 20:10 UTC
Last Modified: 2009-07-03 19:18 UTC
======================================================================
Summary: posix_openpt() and grantpt()
Description:
_____________________________________________________________________________
COMMENT Enhancement Request
Number 26
ed:xxxxxxxxxxx Defect in XSH posix_openpt (rdvk#
1)
{n/a} Mon, 16 Feb 2009 17:57:21
GMT
_____________________________________________________________________________
I guess a small change to the spec could be made to make implementing
pseudo-terminals on various operating systems more simple and more
secure:
The posix_openpt() is often used in combination with grantpt() and
unlockpt(). Many operating systems will create a pseudo-terminal on
demand, instead of recycling it. Linux uses /dev/ptmx and a file system
called devpts, mounted on /dev/pts. In FreeBSD CURRENT, posix_openpt()
is implemented as a system call, which allocates a TTY and exposes its
device node in devfs.
I haven't seen a single piece of software that calls grantpt() on a
file descriptor multiple times, or changes the real UID before calling
grantpt(). I guess it would be a lot simpler for operating systems to
implement this, if there was some kind of provision that if
posix_openpt() already performs the necessary steps to change the
owner/group of the pseudo-terminal and performs an action similar to
unlockpt(), the grantpt() and unlockpt() functions may be implemented
as no-ops. I would almost advise to mark grantpt() and unlockpt() as
obsolete, but that would break a lot of stuff, I guess.
Right now some operating systems use setuid binaries to change the
owner of the pseudo-terminal. By changing the specification as
described above, operating systems will never need some `supernatural'
function to bypass UNIX permissions to chown()/chmod() a character
device they don't own.
Desired Action:
Change grantpt() and unlockpt() to mention:
These functions may have no effect on implementations where similar
actions are already performed by posix_openpt().
======================================================================
----------------------------------------------------------------------
(0000137) msbrown (manager) - 2009-06-29 20:11
http://austingroupbugs.net/view.php?id=96#c137
----------------------------------------------------------------------
Based on the information presented the review group feel that the
change is not necessary.
----------------------------------------------------------------------
(0000152) EdSchouten (updater) - 2009-07-03 19:18
http://austingroupbugs.net/view.php?id=96#c152
----------------------------------------------------------------------
Hi,
I read the teleconference transcript after the issue had been discussed,
but unfortunately it didn't contain any explanation as to why it had been
closed.
Stimulating users of this programming interface to create pseudo-terminals
by regular uids would also make it possible to implement complex access
controls to pseudo-terminals more easily.
|