[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: libc/5055 - [BUG] getpt() does not detect /dev/pts due to wrong

From: Sreeji K Das
Subject: Fwd: Re: libc/5055 - [BUG] getpt() does not detect /dev/pts due to wrong statfs()
Date: Wed, 18 Jun 2003 06:17:36 +0100 (BST)

I'm giving it another try - hopefully I'd be lucky
this time ;-)

I've pasted the original PR for reference. This was
closed as a Vendor Problem. I'd like to follow up with
the vendor; but before that I'd like to know what
really the vendor should fix.

Can anyone help me with a bit of info. as to why it's
a vendor problem ? 

 getpt() returns an fd, which is reported as
"/dev/ttypXX" by ptsname(). ie. getpt() falls through
to bsd_getpt(), eventhough UNIX98 Psedo Term. is

This is due to the following:
1) __posix_openpt() opens "/dev/ptmx", which is
2) Then the following code is executed:
if (fd != -1)
  struct statfs fsbuf;
  static int devpts_mounted;

  /* Check that the /dev/pts filesystem is mounted
   or if /dev is a devfs filesystem (this implies
/dev/pts).  */
   if (devpts_mounted
       || (__statfs (_PATH_DEVPTS, &fsbuf) == 0
        && fsbuf.f_type == DEVPTS_SUPER_MAGIC)
       || (__statfs (_PATH_DEV, &fsbuf) == 0
       && fsbuf.f_type == DEVFS_SUPER_MAGIC))

In the above, _PATH_DEVPTS is defined as :
#define _PATH_DEVPTS _PATH_DEV "pts"
ie. "/dev/pts"
So the above statfs() stats "/dev/pts", which is a
directory in the filesystem.
On my system:
 $ mount|grep pts
  none on /dev/pts type devpts (rw,gid=5,mode=620)
 $ ls -ld /dev/pts
 drwxr-xr-x    2 root     root            0 Jun 10
16:07 /dev/pts/

Due to the above (/dev/ is not devfs and /dev/pts is a
directory), the magic is not what's expected. Hence
getpt() decides UNIX98 pty is not available and falls
through to bsd_getpt().

I did a bit of search (but not hard enough) and did
not find this problem reported anywhere. If it's
already fixed, would some1 know where I should look ?

I'm not an expert, but I think the correct fix would
be to call ptsname() on the returned fd and then
statfs() the slave. ie. a statfs() on /dev/pts/X would
fsbuf.f_type == DEVPTS_SUPER_MAGIC. I've tested this
with a small script.
I don't know if there's a better solution - if not
send in a patch with the above solution.

 I'd like to get this fixed, because if getpt()
allocates a /dev/ttypX, then subsequent grantpt()
would have to invoke the suid script pt_chown. On
Redhat AS2.1, pt_chown has 600 as permissions.
If /dev/ptmx is used, then this script is never
invoked by grantpt() (which is a good thing, as
pt_chown shd. be suid), as a /dev/pts/X is always
owned by the user who created it.


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
--- Begin Message --- Subject: Re: libc/5055 Date: Mon, 16 Jun 2003 06:07:45 +0100 (BST)
Hi Ulrich,

I was under the impression the bug is due to the wrong
statfs() in libc. Am I wrong here ? Can you help me
see the light ? If I'm to report the bug to Redhat
(who's the vendor), am I to say it's a libc bug ? If
it's not a bug in libc, then I'm confused as to where
the bug is.

Or, are you referring to the issue of permissions for
pt_chown ? I agree it's a vendor issue, but I don't
want pt_chown ever getting called, because /dev/ptmx
*is* available and the PTS (/dev/pts/XX) would be
owned by the effective uid - hence there's no need for
grantpt() to call pt_chown. Perms. to pt_chown is a
different issue altogether.

Would greatly appreciate a response.

 --- address@hidden wrote: > Synopsis: [BUG] getpt()
does not detect /dev/pts due
> to wrong statfs()
> State-Changed-From-To: open->closed
> State-Changed-By: drepper
> State-Changed-When: Sat, 14 Jun 2003 12:24:57 -0400
> State-Changed-Why:
> Report this to your vendor.  This does not belong
> here.

Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

Bug-glibc mailing list

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]