unix98 ptys

["Alex Hornung" <ahornung@xxxxxxxxx>]

Hi all,

 

I've recently commited both the kernel and userland part of unix98 ptys, so I'm giving a short description of what happened and what to do if problems arise.

 

What are unix98 ptys?

 

Unix98 ptys are just a new standard for ptys. They basically revolve around /dev/ptmx (to open a master pty) and /dev/pts/XXX, where XXX is a number, for slaves.

BSD ptys are limited to 256 ptys, due to the chosen nomenclature. Unix98 ptys are limited to 1000 ptys due to the line length of utmp (8 bytes), which allows for at most "pts/999" (plus a terminating '\0'). See utmp(5) man page for more info on this.

 

 

What happened?

 

New userland functions in libc are:

* posix_openpt[1] - Implemented as standard dictates (basically just opening /dev/ptmx)

* ptsname[2] - Implemented as standard dictates

* grantpt[3] - No-op, as the kernel already creates the pty dynamically with all the right permissions and ownership (see permissions further down). Following the standard would add a security risk here, imho. Every single bit of code I've ever seen using grantpt, only does so to follow the standard, not expecting it to do anything.

* unlockpt[4] - No-op, as it really has no use whatsoever with dynamically created ptys.

 

I've also migrated openpty(3) to first try and use unix98 ptys, and if any part of that fails, to fall back to the old BSD ptys. Old BSD ptys can still be used as they always have been used; nothing has changed for them. As a matter of fact some programs, as xterm < 247 and aterm don't even use openpty(3) and just find a free BSD pty (/dev/pty**), so expect to still see quite a few /dev/pty** and family.

 

Permissions (as specified in grantpt standard[3]) are the following:

For slaves: <real uid>, group "tty", 0620

For master: <real uid>, group "wheel", 0600   but it doesn't matter, because the master device cannot be opened more than once. Every time /dev/ptmx is opened, a different master is acquired.

 

 

Troubleshooting?

 

Make sure you have all the commits relating to unix98 ptys. If something is still wrong, please do:

sysctl kern.pty_debug=1

This will enable some basic debugging for unix98 ptys which should be enough for most (critical) problems. If you find any other problem, especially with some program doing "something" weird, don't hesitate to contact me.

 

 

Cheers,

Alex Hornung

 

 

References:

[1]: http://www.opengroup.org/onlinepubs/000095399/functions/posix_openpt.html

[2]: http://www.opengroup.org/onlinepubs/000095399/functions/ptsname.html

[3]: http://www.opengroup.org/onlinepubs/000095399/functions/grantpt.html

[4]: http://www.opengroup.org/onlinepubs/000095399/functions/unlockpt.html