5.8.9 won't run suid program

[p5pRT]

Migrated from rt.perl.org#61592 (status was 'rejected')

Searchable as RT61592$

[p5pRT]

From fc@fc.freebsd.org

Created by craig@animalhead.com

Built 5.8.9 from source with conditions identical to those under which our
internet hosting provider built the 5.8.7 under which their suid-cgi
control panel operates correctly.

But the resulting perl5.8.9 would not run the control panel. The following
error message was produced in error_log​: 'suidperl needs (suid) fd script'.

grep told me that the message was in perl.c. An inspection of the code
just preceding the error message revealed that a line had been changed
incorrectly between 5.8.8 and 5.8.9​:

in perl.c in release 5.8.9, line 3727 is if (*suidscript) {
  should be if (*suidscript != 1) {

Making this change, rebuilding perl, and restarting Apache makes the
control panel operate correcty.

Releasing a simple clerical error like this does not speak well for the
testing of the suidperl feature, but there's a rumor it's deprecated.

You're welcome,
cmac
www.animalhead.com

Perl Info

Flags:
    category=core
    severity=critical

Site configuration information for perl v5.8.9:

Configured by <private> at Sun Dec 21 12:20:21 PST 2008.

Summary of my perl5 (revision 5 version 8 subversion 9) configuration:
  Platform:
    osname=freebsd, osvers=6.3-release, archname=i386-freebsd
    uname='freebsd sakomina.securesites.net 6.3-release freebsd 6.3-release #2: wed jun 25 14:30:46 mdt 2008 root@fc:usrsrcsysi386compilevkern i386 '
    config_args='-Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/perl5/5.8.7:/usr/local/lib/perl5/5.00503:/usr/local/lib/site_perl -Dvendorprefix=/usr/local -Dmyhostname=fc -Dmydomain=freebsd.org'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include',
    optimize='-O',
    cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='3.4.6 [FreeBSD] 20060305', 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 ='-Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lgdbm -lm -lcrypt -lutil -lc
    perllibs=-lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.9:
    /usr/local/lib/perl5/5.8.9/i386-freebsd
    /usr/local/lib/perl5/5.8.9
    /usr/local/lib/perl5/site_perl/5.8.9/i386-freebsd
    /usr/local/lib/perl5/site_perl/5.8.9
    /usr/local/lib/perl5/site_perl/5.8.8/i386-freebsd
    /usr/local/lib/perl5/site_perl/5.8.8
    /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd
    /usr/local/lib/perl5/site_perl/5.8.7
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/vendor_perl/5.8.9/i386-freebsd
    /usr/local/lib/perl5/vendor_perl/5.8.9
    /usr/local/lib/perl5/vendor_perl/5.8.7/i386-freebsd
    /usr/local/lib/perl5/vendor_perl/5.8.7
    /usr/local/lib/perl5/vendor_perl
    /usr/local/lib/perl5/5.8.7/i386-freebsd
    /usr/local/lib/perl5/5.8.7
    /usr/local/lib/perl5/5.00503
    /usr/local/lib/site_perl
    .


Environment for perl v5.8.9:
    HOME=/home/<private>
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/local/apache2/bin:/home/sakomina/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

[p5pRT]

From @nwc10

Thanks for the bug report.

On Sun, Dec 21, 2008 at 09​:30​:26PM -0800, fc@​fc.freebsd.org (via RT) wrote​:

Built 5.8.9 from source with conditions identical to those under which our
internet hosting provider built the 5.8.7 under which their suid-cgi
control panel operates correctly.

But the resulting perl5.8.9 would not run the control panel. The following
error message was produced in error_log​: 'suidperl needs (suid) fd script'.

grep told me that the message was in perl.c. An inspection of the code
just preceding the error message revealed that a line had been changed
incorrectly between 5.8.8 and 5.8.9​:

in perl.c in release 5.8.9, line 3727 is if (*suidscript) {
should be if (*suidscript != 1) {

Making this change, rebuilding perl, and restarting Apache makes the
control panel operate correcty.

Releasing a simple clerical error like this does not speak well for the
testing of the suidperl feature, but there's a rumor it's deprecated.

Yes, suidperl is deprecated, and, that does appear to be the correct fix for
a refactoring made in January this year.

You are correct that it suggests that the suidperl is under tested. We know
that our tests are not perfect, and suidperl is impossible to test with
conventional regression tests, as it requires access to root privileges.

However, in the 4 weeks and two release candidates for 5.8.9 it seems that
no-one who relies on this feature chose to actually test their code with
the upcoming Perl code.

Had anyone who needed it actually tested it, this bug would have been averted.

Nicholas Clark

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From Robin.Barker@npl.co.uk

in perl.c in release 5.8.9, line 3727 is if (*suidscript) {
should be if (*suidscript != 1) {

suidscript is a bool* so comparison with 1 is not sound

Elsewhere in patch 33168, C<suidscript != 1> is replaced by C<!suidscript> so I suspect the test is just inverted
  if (*suidscript) {
should be if (!*suidscript) {

Robin

[p5pRT]

From @jkeenan

On Mon Dec 22 07​:26​:41 2008, nicholas wrote​:

Thanks for the bug report.

On Sun, Dec 21, 2008 at 09​:30​:26PM -0800, fc@​fc.freebsd.org (via RT)
wrote​:

Built 5.8.9 from source with conditions identical to those under
which our
internet hosting provider built the 5.8.7 under which their suid-cgi
control panel operates correctly.

But the resulting perl5.8.9 would not run the control panel. The
following
error message was produced in error_log​: 'suidperl needs (suid) fd
script'.

grep told me that the message was in perl.c. An inspection of the
code
just preceding the error message revealed that a line had been
changed
incorrectly between 5.8.8 and 5.8.9​:

in perl.c in release 5.8.9, line 3727 is if (*suidscript) {
should be if (*suidscript !=
1) {

Making this change, rebuilding perl, and restarting Apache makes the
control panel operate correcty.

Releasing a simple clerical error like this does not speak well for
the
testing of the suidperl feature, but there's a rumor it's
deprecated.

Yes, suidperl is deprecated, and, that does appear to be the correct
fix for
a refactoring made in January this year.

You are correct that it suggests that the suidperl is under tested. We
know
that our tests are not perfect, and suidperl is impossible to test
with
conventional regression tests, as it requires access to root
privileges.

However, in the 4 weeks and two release candidates for 5.8.9 it seems
that
no-one who relies on this feature chose to actually test their code
with
the upcoming Perl code.

Had anyone who needed it actually tested it, this bug would have been
averted.

Nicholas Clark

Nicholas,

I suspect we should have closed this ticket four years ago. Do you agree?

Thank you very much.
Jim Keenan

[p5pRT]

From @nwc10

On Sun, Feb 24, 2013 at 02​:59​:58PM -0800, James E Keenan via RT wrote​:

On Mon Dec 22 07​:26​:41 2008, nicholas wrote​:

Nicholas,

I suspect we should have closed this ticket four years ago. Do you agree?

It was not clear 4 years ago whether there would be a 5.8.10 release.
Had there been one, this fix would have been in.*

Also, really, this ticket is "abandoned" rather than "resolved".

I hope that the RT upgrade will let us make that distinction.

Nicholas Clark

* Actually, by the workflow that we're currently using, because we don't have
  a "pending release" status, this ticket would actually have been closed as
  "resolved" as soon as the bug fix was committed, even though it never got
  released. That's also something we should change.

[p5pRT]

From @jkeenan

On Mon Feb 25 04​:30​:04 2013, nicholas wrote​:

On Sun, Feb 24, 2013 at 02​:59​:58PM -0800, James E Keenan via RT wrote​:

On Mon Dec 22 07​:26​:41 2008, nicholas wrote​:

Nicholas,

I suspect we should have closed this ticket four years ago. Do you
agree?

It was not clear 4 years ago whether there would be a 5.8.10 release.
Had there been one, this fix would have been in.*

Also, really, this ticket is "abandoned" rather than "resolved".

I hope that the RT upgrade will let us make that distinction.

Don't hold your breath ;-)

Nicholas Clark

* Actually, by the workflow that we're currently using, because we
don't have
a "pending release" status, this ticket would actually have been
closed as
"resolved" as soon as the bug fix was committed, even though it
never got
released. That's also something we should change.

Can we close the ticket now and, if so, with which Status?

Thank you very much.
Jim Keenan

[p5pRT]

From @nwc10

On Thu, May 09, 2013 at 06​:42​:49PM -0700, James E Keenan via RT wrote​:

On Mon Feb 25 04​:30​:04 2013, nicholas wrote​:

On Sun, Feb 24, 2013 at 02​:59​:58PM -0800, James E Keenan via RT wrote​:

On Mon Dec 22 07​:26​:41 2008, nicholas wrote​:

Nicholas,

I suspect we should have closed this ticket four years ago. Do you
agree?

It was not clear 4 years ago whether there would be a 5.8.10 release.
Had there been one, this fix would have been in.*

Also, really, this ticket is "abandoned" rather than "resolved".

I hope that the RT upgrade will let us make that distinction.

Don't hold your breath ;-)

I haven't been. But the rt.cpan.org update is done, out there and looking
good. I had been hoping that rt.perl.org wouldn't be that many months later.

* Actually, by the workflow that we're currently using, because we
don't have
a "pending release" status, this ticket would actually have been
closed as
"resolved" as soon as the bug fix was committed, even though it
never got
released. That's also something we should change.

Can we close the ticket now and, if so, with which Status?

I believe so. There won't be a release which fixes this.
Not sure. Maybe "wontfix" is the best of the optionso available to us,
although really I'd still like an "abandoned" status. And a
"pending release". And, I guess, for completeness, a terse word which means
"fix is shipped in a newer stable release and we're not going to backport it,
so please upgrade". I think that those 3 are sufficient.

(Which, actually, applies to this ticket, as it was fixed for 5.10.1)

Nicholas Clark

[p5pRT]

From @jkeenan

On Sat May 11 06​:08​:07 2013, nicholas wrote​:

Can we close the ticket now and, if so, with which Status?

I believe so. There won't be a release which fixes this.
Not sure. Maybe "wontfix" is the best of the optionso available to us,
although really I'd still like an "abandoned" status. And a
"pending release". And, I guess, for completeness, a terse word which
means
"fix is shipped in a newer stable release and we're not going to
backport it,
so please upgrade". I think that those 3 are sufficient.

(Which, actually, applies to this ticket, as it was fixed for 5.10.1)

Nicholas Clark

As Nicholas says​:

"Fix is shipped in a newer stable release and we're not going to
backport it, so please upgrade."

Resolved as Rejected, which is the closest we have to Won't Fix.

[p5pRT]

@jkeenan - Status changed from 'open' to 'rejected'