Bug 506219 - mode parameter for devpts missing
Summary: mode parameter for devpts missing
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 11
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 510382 (view as bug list)
Depends On:
Blocks: 509632 513462
TreeView+ depends on / blocked
 
Reported: 2009-06-16 06:26 UTC by Ulrich Drepper
Modified: 2009-08-12 14:20 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-08-12 14:20:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ulrich Drepper 2009-06-16 06:26:06 UTC
Description of problem:
In previous releases devpts in /etc/fstab was correctly introduced with

devpts                  /dev/pts                devpts  gid=5,mode=620  0 0

The options are important.  Group tty and mode 620.

In F11 the line is

devpts                  /dev/pts                devpts  defaults        0 0

At least the default mode is wrong (it is 600).

glibc made the assumption that if devpts is used the options are set correctly.  Silly me, I thought such a bug in the setup cannot happen.  I've changed glibc to not make this assumption but the setup should really be fixed, too.  Otherwise grantpt has to run the pt_chown SUID program which is slow (and broken in F11, wrong permission).  Basically, F11 has an unusable grantpt function.



Version-Release number of selected component (if applicable):
setup-2.8.3-1.fc11.noarch

How reproducible:
always

Steps to Reproduce:
1.compile the code below
2.run
3.
  
Actual results:
Mode for the new descriptor is 0600 and group is that of the user

Expected results:
Mode is 0620 and group is tty.

Additional info:

Test program.  After the grantpt call the permission should be 620 and the group tty.

#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int
main()
{
  int fd = open ("/dev/ptmx", O_RDWR);
  if (fd < 0) {
    puts ("open failed");
    return 1;
  }
  system ("ls -l /dev/pts");
  if (grantpt (fd) < 0) {
    puts ("grantpt failed");
    return 1;
  }
  puts ("aaa");
  char *s = ptsname (fd);
  if (s == NULL) {
    puts ("ptsname failed");
    return 1;
  }
  puts (s);
  system ("ls -l /dev/pts");
  close (fd);
  return 0;
}

Comment 1 Ondrej Vasik 2009-06-16 18:49:30 UTC
Thanks for report, setup owns that file, but just creates empty /etc/fstab file - it is filled by anaconda. I guess devpts entry is added there. Therefore reassigning...

Comment 2 Jakub Jelinek 2009-06-16 23:00:23 UTC
I see
class DevPtsFS(NoDevFS):                                                 
    """ devpts filesystem. """                            
    _type = "devpts"                                           
    _defaultMountOptions = ["gid=5", "mode=620"]
in storage/formats/fs.py, so it doesn't look like an intended change from F10.

Comment 3 Andreas Schwab 2009-07-08 14:26:34 UTC
I have "gid=5,mode=620" in both in /etc/fstab and /etc/mtab, yet /proc/mounts lists the options as "rw,relatime,mode=600,ptmxmode=000", so it seems whatever mounts that fs is ignoring the fstab options.

Comment 4 Andreas Schwab 2009-07-08 14:51:24 UTC
Looking closer this is a side effect of bug 510183: there is only a single system-wide set of options for the devpts filesystem, so another mount of it with the wrong options overwrites them for all mounts.

Comment 5 Ondrej Vasik 2009-07-09 05:52:56 UTC
*** Bug 510382 has been marked as a duplicate of this bug. ***

Comment 6 Yanko Kaneti 2009-07-09 14:47:53 UTC
FWIW a fresh minimal f11+updates_repo install today produces a fstab entry with only "defaults" , which I guess leaves it to the kernel with the end result of 
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
Despite that the anacoda code above should be on the f11 install media.

btw if 620 should be the default, should this line be changed?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/devpts/inode.c;hb=HEAD#l29

Comment 7 Chris Lumens 2009-08-12 14:20:22 UTC
The /etc/fstab and the mount output both show that anaconda's doing the right thing here, so if there's still a bug present then it's definitely not in anaconda anymore.


Note You need to log in before you can comment on or make changes to this bug.