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

[Sreeji K Das]

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 ? 
Sreeji

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

This is due to the following:
(unix/sysv/linux/getpt.c)
1) __posix_openpt() opens "/dev/ptmx", which is
successful.
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 ?

 Fix:
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
return
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
I'll 
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.

thx
Sreeji


________________________________________________________________________
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.
> Sreeji
>
>  --- 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-glibc
>
> --- End Message ---