Perl with setuid enabled

[prattm]

We have a bunch of Perl scripts on our system, all of which use the
following header:

#!/bin/ksh -- # -*- perl -*-
eval 'exec ${PERL} $0 ${1+"$@"}'
if 0;

The idea is we maintain a common variable $PERL that points to our
latest version. This works fine and dandy, but one particular script
is running with setuid enabled (4110 permission) and has problems with
this header. It prints out the message:

Unrecognized character \x7F at /bin/ksh line 1.

The character 7F is the "delete" character, but I copied and pasted the
ksh header from another script that works, so I don't believe there is
any hidden character(s). We've also tried something like:

#!${PERL}

but that didn't work. The only way to get it to work is to hardcode the
path to perl executable, but this requires more maintenance when
upgrading our version of perl and we'd like to avoid it if possible.
Anyone have any ideas?

Thanks, Mike

 

[Mark Clements]

We have a bunch of Perl scripts on our system, all of which use the
following header:

#!/bin/ksh -- # -*- perl -*-
eval 'exec ${PERL} $0 ${1+"$@"}'
if 0;

The idea is we maintain a common variable $PERL that points to our
latest version. This works fine and dandy, but one particular script
is running with setuid enabled (4110 permission) and has problems with
this header. It prints out the message:

Unrecognized character \x7F at /bin/ksh line 1.

The character 7F is the "delete" character, but I copied and pasted the
ksh header from another script that works, so I don't believe there is
any hidden character(s). We've also tried something like:

#!${PERL}

but that didn't work. The only way to get it to work is to hardcode the
path to perl executable, but this requires more maintenance when
upgrading our version of perl and we'd like to avoid it if possible.
Anyone have any ideas?

You can have multiple versions of perl installed on each system. You
could have symlinks pointing at the latest version, and then each script
just starts

#!/usr/local/bin/perl

or somesuch.

Mark

 

[prattm]

Dan,

I tried several variations of your idea below but never could get the
correct version to run (it kept defaulting to 5.003 in /usr/bin,
whereas I'd it to use 5.8.6 that we built ourselves). What's weird is
I can do it on the command line just fine:

/usr/bin/env ${PERL} -v

It prints out 5.8.6, no problem. But when I throw this in a file and
try to execute it, it gives me "/usr/bin/env: Directory or file not
found" (with exit code 127, meaning it cannot find whatever $PERL is
pointing to).

The good news is, /usr/bin/perl is current enough to let script do what
it needs (as far as running in taint mode), but it would still be nice
to use to most recent version we have built.

Thanks for the input,

Mike

 

[Peter J. Holzer]

We have a bunch of Perl scripts on our system, all of which use the
following header:

#!/bin/ksh -- # -*- perl -*-
eval 'exec ${PERL} $0 ${1+"$@"}'
if 0;

The idea is we maintain a common variable $PERL that points to our
latest version. This works fine and dandy, but one particular script
is running with setuid enabled (4110 permission) and has problems with
this header.

That looks positively dangerous. If I can invoke that script at all, I
can get it to do anything by providing a suitable PERL variable.

It prints out the message:

Unrecognized character \x7F at /bin/ksh line 1.

That may be a combination of the 4110 permission and a bug in ksh (you
don't write which OS you are using). Scripts normally need to be
readably (not just executable) by the effective user id of the
interpreter process (because the interpreter has to read the script
before it can interpret it). Since your script has 04110 permission, the
ksh cannot open it, and the 0x7F character may just be the lower 7 bits
of the -1 return code that it got while trying to read from a
non-existing file descriptor. Change the permissions to 04510 and it
should work if your OS supports setuid scripts at all (some Unixes (e.g.
Linux) don't for good reasons).

hp