Bug 506219 - mode parameter for devpts missing
mode parameter for devpts missing
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
: 510382 (view as bug list)
Depends On:
Blocks: 513462 509632
  Show dependency treegraph
Reported: 2009-06-16 02:26 EDT by Ulrich Drepper
Modified: 2009-08-12 10:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-12 10:20:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2009-06-16 02:26:06 EDT
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):

How reproducible:

Steps to Reproduce:
1.compile the code below
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 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 14:49:30 EDT
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 19:00:23 EDT
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 10:26:34 EDT
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 10:51:24 EDT
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 01:52:56 EDT
*** Bug 510382 has been marked as a duplicate of this bug. ***
Comment 6 Yanko Kaneti 2009-07-09 10:47:53 EDT
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?
Comment 7 Chris Lumens 2009-08-12 10:20:22 EDT
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.