No error on assignment to $>

[p5pRT]

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

Searchable as RT3242$

[p5pRT]

From mjtg@cus.cam.ac.uk

Shouldn't this (run in an unprivileged environment) cause some sort
of error or at least a warning, rather than the assignment being
silently ignored?

  perl5.6.0 -wle '$> = 0; print $>'
  1189

Mike Guy

% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration​:
  Platform​:
  osname=solaris, osvers=2.6, archname=sun4-solaris
  uname=''
  config_args='-dOes -f confug.sh'
  hint=previous, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
  useperlio=undef d_sfio=undef uselargefiles=define
  use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler​:
  cc='gcc', optimize='-O', gccversion=2.7.2.3
  cppflags='-I/usr/local/include -I/opt/local/include -DREG_INFTY=22786'
  ccflags ='-I/usr/local/include -I/opt/local/include -DREG_INFTY=22786'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags =' -L/usr/local/lib -L/opt/local/lib'
  libpth=/usr/local/lib /opt/local/lib /lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-fpic', lddlflags='-G -L/usr/local/lib -L/opt/local/lib'

Characteristics of this binary (from libperl)​:
  Compile-time options​: USE_LARGE_FILES
  Locally applied patches​:
  diag.format
  perldoc.vers
  installman.opt
  undef.opcode
  Built under solaris
  Compiled at Apr 4 2000 17​:17​:26
  @​INC​:
  /home/mjtg/perl5.6.0/lib
  /home/mjtg/perl5.6.0/lib
  /home/mjtg/perl5.6.0/lib
  /home/mjtg/perl5.6.0/lib
  .

[p5pRT]

From [Unknown Contact. See original ticket]

Shouldn't this (run in an unprivileged environment) cause some sort
of error or at least a warning, rather than the assignment being
silently ignored?

   perl5\.6\.0 \-wle '$> = 0; print $>'
   1189

Perl doesn't give warnings on syscall failures.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen <tchrist@​chthon.perl.com> wrote

Perl doesn't give warnings on syscall failures.

Ah! Of course it doesn't. Silly me.

But perhaps the documentation of $> (and all the rest that hide system
calls) should the mention the need to check $! afterwards. And
therefore the need to set $! to 0 first, since there's no other way of
detecting success/failure.

Mike Guy

[p5pRT]

From @smpeters

[RT_System - Fri May 12 04​:40​:31 2000]​:

Tom Christiansen <tchrist@​chthon.perl.com> wrote

Perl doesn't give warnings on syscall failures.

Ah! Of course it doesn't. Silly me.

But perhaps the documentation of $> (and all the rest that hide system
calls) should the mention the need to check $! afterwards. And
therefore the need to set $! to 0 first, since there's no other way of
detecting success/failure.

Mike Guy

Attached is a patch to perlvar.pod to document the variables I found
that implement a system call underneath.

[p5pRT]

From @smpeters

perlvar.pod.patch

--- perlvar.pod.orig	Sat Nov 20 22:18:40 2004
+++ perlvar.pod	Sat Nov 20 22:34:55 2004
@@ -765,7 +765,9 @@
 
 The real uid of this process.  (Mnemonic: it's the uid you came I<from>,
 if you're running setuid.)  You can change both the real uid and
-the effective uid at the same time by using POSIX::setuid().
+the effective uid at the same time by using POSIX::setuid().  Since
+changes to $< require a system call, check $! after a change attempt to 
+detect any possible errors.
 
 =item $EFFECTIVE_USER_ID
 
@@ -779,7 +781,8 @@
     ($<,$>) = ($>,$<);	# swap real and effective uid
 
 You can change both the effective uid and the real uid at the same
-time by using POSIX::setuid().
+time by using POSIX::setuid().  Changes to $> require a check to $!
+to detect any possible errors after an attempted change. 
 
 (Mnemonic: it's the uid you went I<to>, if you're running setuid.)
 C<< $< >> and C<< $> >> can be swapped only on machines
@@ -802,7 +805,8 @@
 back to C<$(> without being forced numeric, such as by adding zero.
 
 You can change both the real gid and the effective gid at the same
-time by using POSIX::setgid().
+time by using POSIX::setgid().  Changes to $( require a check to $!
+to detect any possible errors after an attempted change.
 
 (Mnemonic: parentheses are used to I<group> things.  The real gid is the
 group you I<left>, if you're running setgid.)
@@ -828,6 +832,8 @@
 
 You can change both the effective gid and the real gid at the same
 time by using POSIX::setgid() (use only a single numeric argument).
+Changes to $) require a check to $! to detect any possible errors
+after an attempted change.
 
 (Mnemonic: parentheses are used to I<group> things.  The effective gid
 is the group that's I<right> for you, if you're running setgid.)

[p5pRT]

From rick@bort.ca

On Sun, Nov 21, 2004 at 04​:38​:09AM -0000, Steve Peters via RT wrote​:

[RT_System - Fri May 12 04​:40​:31 2000]​:

Tom Christiansen <tchrist@​chthon.perl.com> wrote

Perl doesn't give warnings on syscall failures.

Ah! Of course it doesn't. Silly me.

But perhaps the documentation of $> (and all the rest that hide system
calls) should the mention the need to check $! afterwards. And
therefore the need to set $! to 0 first, since there's no other way of
detecting success/failure.

Mike Guy

Attached is a patch to perlvar.pod to document the variables I found
that implement a system call underneath.

You neglected to mention the need to initialize $! to 0 before the
store. Though I personally don't see any reason not to warn in these
cases.

--
Rick Delaney
rick@​bort.ca

[p5pRT]

From @rgs

Steve Peters via RT wrote​:

But perhaps the documentation of $> (and all the rest that hide system
calls) should the mention the need to check $! afterwards. And
therefore the need to set $! to 0 first, since there's no other way of
detecting success/failure.

Attached is a patch to perlvar.pod to document the variables I found
that implement a system call underneath.

Thanks, applied as change #23532 to bleadperl.

--
Phil Blake's weekly Pat and Bull story. Uncle Toby's page for tiny tots.
  -- Ulysses

[p5pRT]

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