Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make test breaks permissions on /dev/tty #6938

Closed
p5pRT opened this issue Nov 19, 2003 · 4 comments
Closed

make test breaks permissions on /dev/tty #6938

p5pRT opened this issue Nov 19, 2003 · 4 comments

Comments

@p5pRT
Copy link

p5pRT commented Nov 19, 2003

Migrated from rt.perl.org#24521 (status was 'resolved')

Searchable as RT24521$

@p5pRT
Copy link
Author

p5pRT commented Nov 19, 2003

From menscher+bug@uiuc.edu

Created by menscher+bug@uiuc.edu

When running "make test" from the perl source tree, the permissions
of /dev/tty get changed from 0666 to 2775. This obviously breaks
a unix system pretty badly.

I've traced the problem to one of the tests performed in
  ${PERL_582_SOURCE}/t/lib/warnings/doio

The specific test that is breaking things is Perl_nextargv.

When this program gets called with a file redirected into it
(the Makefile runs "./perl TEST </dev/tty", and I think the
/dev/tty is passed through the testing procedure), it changes
that file's permissions from 0666 to 2775 (if run as root) or to
2755 (if run as a user).

I'm a complete novice, so hopefully this is enough for you to
understand the problem. If not, maybe this code segment (taken
from the doio test procedure) will be easier to understand​:

---snip---
#!/usr/local/bin/perl
$^W = 0 ;
my $filename = "./temp.dir" ;
mkdir $filename, 0777
  or die "Cannot create directory $filename​: $!\n" ;
system("chmod 666 blah");
print("permissions reset to​:\n");
system("ls -l blah");
{
  local (@​ARGV) = ($filename) ;
  local ($^I) = "" ;
  my $x = <> ;
}
system("ls -l blah");
system("chmod 666 blah");
print("permissions reset to​:\n");
system("ls -l blah");
{
  local (@​ARGV) = ($filename) ;
  local ($^I) = "" ;
  my $x = <> ;
}
system("ls -l blah");
rmdir $filename ;
---snip---

Save that as bug.py and do​:
$ touch blah
$ ./bug.py <blah

It will hopefully then be evident what the problem is.

We have seen this on three machines (RH7.3 and RH9). I've also
confirmed that this test program changes permissions with perl-5.6.1
under IRIX 6.5.21m. So perhaps the program is working as intended,
and it's just the "make test" script that's broken?

I'm marking it critical since it has the potential to break a Unix
machine in a very bad (and hard to track down!) way.

Damian Menscher
--
-=#| Physics Grad Student & SysAdmin @​ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc​:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group​:(217)244-3074 |#=-
-=#| <menscher@​uiuc.edu> www.uiuc.edu/~menscher/ Fax​:(217)333-9819 |#=-

Perl Info

Flags:
    category=install
    severity=critical

Site configuration information for perl v5.8.2:

Configured by weber at Mon Nov 17 17:52:19 CST 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
  Platform:
    osname=linux, osvers=2.4.20-20.7smp, archname=i686-linux-thread-multi
    uname='linux zeus.itg.uiuc.edu 2.4.20-20.7smp #1 smp mon aug 18 14:46:14 edt 2003 i686 unknown '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.3 2.96-113)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.2:
    /usr/local/encap/perl-5.8.2/lib/5.8.2/i686-linux-thread-multi
    /usr/local/encap/perl-5.8.2/lib/5.8.2
    /usr/local/encap/perl-5.8.2/lib/site_perl/5.8.2/i686-linux-thread-multi
    /usr/local/encap/perl-5.8.2/lib/site_perl/5.8.2
    /usr/local/encap/perl-5.8.2/lib/site_perl
    .


Environment for perl v5.8.2:
    HOME=/home/staff/menscher
    LANG=en_US.iso885915
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:.
    LOGDIR (unset)
    PATH=/bin:/usr/etc:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/bsd:/usr/ucb:/usr/opt/freeware/bin:/etc:/usr/local/bin:/usr/local/sbin:/usr/java/jdk1.3.0_02/bin:/usr/java/bin:.:/usr/java/j2sdk1.4.0_01/bin:/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

@p5pRT
Copy link
Author

p5pRT commented Nov 19, 2003

From guest@guest.guest.xxxxxxxx

Just some more information on this​:

The permissions of the redirected file are being changed only if the
sticky bit (2000) is set on the directory you're running from. If that
is the case, then the permissions get set to the permissions that would
be assigned to a newly-created directory, namely, 2777-umask. The
umask difference between a user and root on my system explains why I
was seeing it set to 2775 when run as root or 2755 when run as a user.

So, it looks like this is more a bug in perl and less a bug in the
install scripts.

Damian (menscher AT uiuc DOT edu)

@p5pRT
Copy link
Author

p5pRT commented Feb 29, 2004

From @iabyn

On Wed, Nov 19, 2003 at 12​:39​:27AM -0000, menscher+bug@​uiuc.edu (via RT) wrote​:

When running "make test" from the perl source tree, the permissions
of /dev/tty get changed from 0666 to 2775. This obviously breaks
a unix system pretty badly.

Thanks for the report, I'm sorry it it's taken us so long to respond.

I've been able to reduce the problem to the following​:

  $ mkdir foo; chmod 2777 foo; # needs SUID or SGID bit set
  $ touch bar;
  $ perl -i -e '$x=<>;$x=<>' foo < bar
  Can't do inplace edit​: foo is not a regular file at -e line 1.

  (bar now has permissions 2777)

This is because on the second read, Perl attempts to restore the
permissions on the previous file, but because the open of the previous
file failed (it wont let you do an inplace edit of a directory),
the variable containing the previous file descriptor is still set at 0,
so it ends up doing an fchmod(0,...). Whoops!

This is now fixed in the development version of Perl by the following
patch.

Dave.

--
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
  -- Larry Wall

Change 22415 by davem@​davem-percy on 2004/02/29 18​:06​:45

  [perl #24521] make test breaks permissions on /dev/tty
  perl -i could fchmod(stdin) by mistake

Affected files ...

... //depot/perl/doio.c#236 edit

Differences ...

==== //depot/perl/doio.c#236 (text) ====

@​@​ -723,11 +723,13 @​@​
  if (PL_filemode & (S_ISUID|S_ISGID)) {
  PerlIO_flush(IoIFP(GvIOn(PL_argvoutgv))); /* chmod must follow last write */
#ifdef HAS_FCHMOD
- (void)fchmod(PL_lastfd,PL_filemode);
+ if (PL_lastfd != -1)
+ (void)fchmod(PL_lastfd,PL_filemode);
#else
  (void)PerlLIO_chmod(PL_oldname,PL_filemode);
#endif
  }
+ PL_lastfd = -1;
  PL_filemode = 0;
  if (!GvAV(gv))
  return Nullfp;

@p5pRT
Copy link
Author

p5pRT commented Feb 29, 2004

@iabyn - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant