qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Todd T. Fries" <qemu-devel@email.fries.net>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] pty/tty functions for BSD too
Date: Tue, 19 Aug 2008 07:35:45 -0500	[thread overview]
Message-ID: <20080819123544.GA30399@fries.net> (raw)
In-Reply-To: <20080818162618.GA20089@redhat.com>

>From the OpenBSD man page...

DESCRIPTION
     The openpty(), login_tty(), and forkpty() functions perform manipulations
     on ttys and pseudo-ttys.

     The openpty() function finds an available pseudo-tty and returns file de-
     scriptors for the master and slave in amaster and aslave.  If name is
     non-null, the filename of the slave is returned in name (a string of at
     least 16 characters).  If termp is non-null, the terminal parameters of
     the slave will be set to the values in termp.  If winp is non-null, the
     window size of the slave will be set to the values in winp.

     The openpty() function works in the following way: first it attempts to
     allocate the pseudo-tty through the /dev/ptm device (see pty(4) for de-
     tails) and if that fails it searches for a free pseudo-tty by iterating
     through all existing pseudo-tty devices in /dev.  When a free pseudo-tty
     is found, its ownership is changed to the UID of the caller, permissions
     are set to correct values, and all earlier uses of that device are re-
     voked (see revoke(2) for details).  The first method can work for any us-
     er, the second method requires super-user privileges in most cases.

In OpenBSD, it's a pretty safe bet that 16chars is overkill.  The tty and/or
pty name will never be longer than /dev/?ty??.

Thanks,
-- 
Todd Fries .. todd@fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Penned by Daniel P. Berrange on 20080818 17:26.18, we have:
| On Mon, Aug 18, 2008 at 07:16:36PM +0300, Blue Swirl wrote:
| > On 8/18/08, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
| > > Anthony Liguori, le Mon 18 Aug 2008 09:06:41 -0500, a ?crit :
| > >
| > > > Samuel Thibault wrote:
| > >  > >In Xen, pty/tty functions are enabled for BSD too, shouldn't we enable
| > >  > >them in upstream qemu too, as patched below?
| > >  > >
| > >  >
| > >  > And you're sure that these functions compile/work on NetBSD/OpenBSD?
| > >
| > >
| > > The defines are explicit in Xen, so I guess somebody tested it.  I
| > >  haven't myself.  I wonder why there is no FreeBSD however.
| > 
| > The patch does not work on OpenBSD, because while openpty() is
| > available, ptsname() isn't.
| > 
| > I tested the attached version on OpenBSD and Linux, pty name is
| > printed correctly.
| 
| Passing a non-NULL value to openpty()'s name parameter is not safe
| 
| [quote openpty(1)]
| BUGS
|        Nobody knows how much space should be reserved for name.  So, call-
|        ing openpty() or forkpty() with non-NULL name may not be secure.
| [/quote]
| 
| If BSD has no other way to determine the PTY name, then at least it
| should be conditionalized so that systems with ptsname() use it, only
| falling back to using the 'name' arg to openpty() for OS lacking ptsname
| 
| Regards,
| Daniel
| -- 
| |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
| |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
| |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
| |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
| 

      parent reply	other threads:[~2008-08-19 12:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 10:59 [Qemu-devel] pty/tty functions for BSD too Samuel Thibault
2008-08-18 14:06 ` Anthony Liguori
2008-08-18 14:23   ` Samuel Thibault
2008-08-18 15:12     ` Warner Losh
2008-08-18 17:18       ` Anthony Liguori
2008-08-18 16:16     ` Blue Swirl
2008-08-18 16:26       ` Daniel P. Berrange
2008-08-18 16:57         ` Blue Swirl
2008-08-18 18:08           ` Blue Swirl
2008-08-18 18:20             ` Daniel P. Berrange
2008-08-18 19:42             ` Jamie Lokier
2008-08-19 10:33             ` Bernhard Reutner-Fischer
2008-08-19 11:21               ` François Revol
2008-08-19 11:40                 ` Bernhard Reutner-Fischer
2008-08-19 12:55                   ` Samuel Thibault
2008-08-19 19:17                     ` Klaus Heinz
2008-08-21 18:16                       ` Blue Swirl
2008-08-19 12:35         ` Todd T. Fries [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080819123544.GA30399@fries.net \
    --to=qemu-devel@email.fries.net \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=todd@fries.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).