[18167] in Perl-Users-Digest
Perl-Users Digest, Issue: 335 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 22 14:05:47 2001
Date: Thu, 22 Feb 2001 11:05:16 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <982868716-v10-i335@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 22 Feb 2001 Volume: 10 Number: 335
Today's topics:
Re: "runtime" code in a module, what block to put in? nobull@mail.com
Re: (OFF TOPIC) Re: This is driving me nuts and I need (Rich Lafferty)
@x=m//gc doesn't keep pos()? jrw32982@my-deja.com
Re: @x=m//gc doesn't keep pos()? <ren@tivoli.com>
Re: DB_File (Anno Siegel)
Disabling debugging support in Perl? <Joshua.Cope@Compaq.com>
Re: email & date question nobull@mail.com
Re: How can I detect if program is run by cron? (Anno Siegel)
Re: How can I detect if program is run by cron? <uri@sysarch.com>
Re: How can I detect if program is run by cron? (Anno Siegel)
Re: How can I detect if program is run by cron? <uri@sysarch.com>
Re: How can I detect if program is run by cron? (Anno Siegel)
Re: Is a function/class library for processing of SMTP- nobull@mail.com
Re: MacPerl help for a newbie <wuerz@yahoo.com>
Re: MacPerl help for a newbie <wuerz@yahoo.com>
Re: MacPerl help for a newbie <bart.lateur@skynet.be>
Re: Perl in UNIX <godzilla@stomp.stomp.tokyo>
Re: Perl in UNIX <godzilla@stomp.stomp.tokyo>
Re: Perl in UNIX nobull@mail.com
Re: Perl in UNIX <mischief@velma.motion.net>
Re: Perl in UNIX <godzilla@stomp.stomp.tokyo>
Re: Perl in UNIX <godzilla@stomp.stomp.tokyo>
Perl Threads -- advice needed <danilche@cs.umass.edu>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Feb 2001 18:23:37 +0000
From: nobull@mail.com
Subject: Re: "runtime" code in a module, what block to put in?
Message-Id: <u9vgq2k252.fsf@wcl-l.bham.ac.uk>
"John Lin" <johnlin@chttl.com.tw> writes:
> Subject: Re: code in a module, what block to put in?
The semantics of use() are entirely compile time. There is no block
of code that is executed when the execution pointer reaches the line
where the use() appeared.
> If my original program is:
>
> die "You are running under Win32, sorry.\n" if $^O eq 'MSWin32';
> print "hello\n";
>
> The result is:
>
> You are running under Win32, sorry.
>
> Now I want to extract common parts into a module:
>
> package CheckOS;
> die "You are running under Win32, sorry.\n" if $^O eq 'MSWin32';
> 1
> ------------------------ checkOS.pl
> use CheckOS;
> print "hello\n";
>
> The die message becomes messy
>
> You are running under Win32, sorry.
> Compilation failed in require at checkOS.pl line 1.
> BEGIN failed--compilation aborted at checkOS.pl line 1.
You only need to use die() if you want your error to be trappable by
the normal exception trapping mechanisms. In this case this appears
to be exactly the opposite of what you want.
It would appear that all you want to do is to print a message to
STDERR and then exit. have you considered doing just that?
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 22 Feb 2001 18:36:29 GMT
From: rich@bofh.concordia.ca (Rich Lafferty)
Subject: Re: (OFF TOPIC) Re: This is driving me nuts and I need a guru
Message-Id: <slrn99an1d.plg.rich@bofh.concordia.ca>
In comp.lang.perl.misc,
Philip 'Yes, that's my address' Newton <nospam.newton@gmx.li> wrote:
> On Mon, 19 Feb 2001 08:07:20 GMT, Beable van Polasm <beable@my-deja.com> wrote:
> >
> > Randal must have meant news.newusers.questions.
>
> I think he did mean news.announce.newusers; however, the periodical
> postings to it appear to have stopped (except for a couple of
> postings such as "how to become a Usenet site" that are cross-posted
> to news.answers).
>
> This is unfortunate and I don't know why they no longer arrive.
Technical problems regarding the moderation address which are
reportedly being looked into. In the meantime, the last copy posted
should be available at <http://www.faqs.org/>.
-Rich
--
Rich Lafferty ----------------------------------------
Nocturnal Aviation Division, IITS Computing Services
Concordia University, Montreal, QC
rich@bofh.concordia.ca -------------------------------
------------------------------
Date: 22 Feb 2001 16:13:55 GMT
From: jrw32982@my-deja.com
Subject: @x=m//gc doesn't keep pos()?
Message-Id: <973ds30jse@news1.newsguy.com>
I thought these two lines would be functionally equivalent, but the second one reports that pos() is undefined. This seems like a bug to me. Can anyone explain?
$_ = "qrqr"; my @y; push @y, $1 while /(q)/gc; print "<@y> ", pos, "\n";
$_ = "qrqr"; my @x = /(q)/gc; print "<@x> ", pos, "\n";
prints:
<q q> 3
<q q>
(with an uninitialized value warning if -w is used).
John Wiersba
==================================
Posted via http://nodevice.com
Linux Programmer's Site
------------------------------
Date: 22 Feb 2001 11:45:43 -0600
From: Ren Maddox <ren@tivoli.com>
Subject: Re: @x=m//gc doesn't keep pos()?
Message-Id: <m3vgq2wr08.fsf@dhcp11-177.support.tivoli.com>
jrw32982@my-deja.com writes:
> I thought these two lines would be functionally equivalent, but the second one reports that pos() is undefined. This seems like a bug to me. Can anyone explain?
>
> $_ = "qrqr"; my @y; push @y, $1 while /(q)/gc; print "<@y> ", pos, "\n";
> $_ = "qrqr"; my @x = /(q)/gc; print "<@x> ", pos, "\n";
>
> prints:
>
> <q q> 3
> <q q>
>
> (with an uninitialized value warning if -w is used).
The documentation for pos should probably mention that this only
applies when "m//g" is used in scalar context. In list context there
is no point where it leaves off as it searches the entire string.
This is covered in perlop(1):
The /g modifier specifies global pattern
matching--that is, matching as many times as
possible within the string. How it behaves
depends on the context. In list context, it
returns a list of all the substrings matched by
all the parentheses in the regular expression. If
there are no parentheses, it returns a list of all
the matched strings, as if there were parentheses
around the whole pattern.
In scalar context, each execution of m//g finds
the next match, returning TRUE if it matches, and
FALSE if there is no further match. The position
after the last match can be read or set using the
pos() function; see the pos entry in the perlfunc
manpage. A failed match normally resets the
search position to the beginning of the string,
but you can avoid that by adding the /c modifier
(e.g. m//gc). Modifying the target string also
resets the search position.
It is fairly clear from this that pos() is only applicable when the
m//g is in scalar context.
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: 22 Feb 2001 16:11:44 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: DB_File
Message-Id: <973do0$ev3$2@mamenchi.zrz.TU-Berlin.DE>
According to TomC <livia74@ctimail3.com>:
> Hi all,
> I read a script with the follwoing lines:
>
> $masterDb_obj = tie(%masterDb, 'DB_File', undef,O_CREAT|O_RDWR, 0644,
> $DB_BTREE);
> $masterDb_obj->sync();
>
> Actually, I don't know the function of sync()?
Then look it up: run "perldoc DB_File" and search for sync.
Anno
------------------------------
Date: Thu, 22 Feb 2001 11:48:09 -0500
From: Joshua Cope <Joshua.Cope@Compaq.com>
Subject: Disabling debugging support in Perl?
Message-Id: <3A9542C9.8449F753@Compaq.com>
I have a site requirement to disable debugging support in all compilers and
interpreters, including Perl. Is there a simple way to disable the Perl
debugger in a runtime environment (that is, without recompiling the Perl
executable)?
Thanks in advance,
Joshua Cope
Compaq OpenVMS Engineering
------------------------------
Date: 22 Feb 2001 18:22:54 +0000
From: nobull@mail.com
Subject: Re: email & date question
Message-Id: <u91ysqlgqp.fsf@wcl-l.bham.ac.uk>
Jian Zhang <jzhang@voodoo.ca.boeing.com> writes:
> I'm mainly an UNIX programmer, but I need some help under NT environment:
>
> 1. On a Window NT server, how do I send email in my perl cgi script?
CGI is irrelevant you do it the same as you would in any other Perl script.
Use one of the Mail modules from CPAN to send mail via an SMTP server.
There may also be modules that utilise non-portable MS proprietory
APIs but I can't see any reason to use them. Use a SMTP based
approach and it'll work anywhere.
> 2. How do I get the current date information under the same environment?
Do you mean in Perl? There's no difference between NT and Unix in
this respect.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 22 Feb 2001 16:06:40 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How can I detect if program is run by cron?
Message-Id: <973deg$ev3$1@mamenchi.zrz.TU-Berlin.DE>
According to hymie! <hymie@lactose.smart.net>:
> In our last episode, the evil Dr. Lacto had captured our hero,
> "John Lin" <johnlin@chttl.com.tw>, who said:
>
> >How to detect whether the program is run by cron?
[...]
> This is probably dependent on which version of Unix you're using.
>
> If you can enable perl's built-in switch parsing (with the -s flag),
> then you can run your script from cron with a -cron switch, and test
> for the existence of the $cron variable.
Ah, a useful application of the -s switch. I like it. It's much
better to tell the program it's running under cron than to conclude
so from circumstantial evidence. Of course, one could try to check
the parent pid, but that's painful.
Anno
------------------------------
Date: Thu, 22 Feb 2001 16:13:51 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: How can I detect if program is run by cron?
Message-Id: <x7g0h6itkw.fsf@home.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> According to hymie! <hymie@lactose.smart.net>:
>> In our last episode, the evil Dr. Lacto had captured our hero,
>> "John Lin" <johnlin@chttl.com.tw>, who said:
>>
>> >How to detect whether the program is run by cron?
AS> [...]
>> This is probably dependent on which version of Unix you're using.
>>
>> If you can enable perl's built-in switch parsing (with the -s flag),
>> then you can run your script from cron with a -cron switch, and test
>> for the existence of the $cron variable.
AS> Ah, a useful application of the -s switch. I like it. It's much
AS> better to tell the program it's running under cron than to conclude
AS> so from circumstantial evidence. Of course, one could try to check
AS> the parent pid, but that's painful.
how would you check the parent pid? cron forks a shell which runs the
command. you can't see the crond pid from your program. the only sure
way is some env or command like argument to the program that is set on
the crontab line.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 22 Feb 2001 16:20:07 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How can I detect if program is run by cron?
Message-Id: <973e7n$ev3$3@mamenchi.zrz.TU-Berlin.DE>
According to Uri Guttman <uri@sysarch.com>:
> >>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
>
> AS> According to hymie! <hymie@lactose.smart.net>:
> >> In our last episode, the evil Dr. Lacto had captured our hero,
> >> "John Lin" <johnlin@chttl.com.tw>, who said:
> >>
> >> >How to detect whether the program is run by cron?
>
> AS> [...]
>
> >> This is probably dependent on which version of Unix you're using.
> >>
> >> If you can enable perl's built-in switch parsing (with the -s flag),
> >> then you can run your script from cron with a -cron switch, and test
> >> for the existence of the $cron variable.
>
> AS> Ah, a useful application of the -s switch. I like it. It's much
> AS> better to tell the program it's running under cron than to conclude
> AS> so from circumstantial evidence. Of course, one could try to check
> AS> the parent pid, but that's painful.
>
> how would you check the parent pid? cron forks a shell which runs the
> command. you can't see the crond pid from your program. the only sure
> way is some env or command like argument to the program that is set on
> the crontab line.
Then check that shell's PPID. I said it'd get messy :)
Anno
------------------------------
Date: Thu, 22 Feb 2001 16:27:34 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: How can I detect if program is run by cron?
Message-Id: <x7d7caisy0.fsf@home.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> According to Uri Guttman <uri@sysarch.com>:
>> how would you check the parent pid? cron forks a shell which runs the
>> command. you can't see the crond pid from your program. the only sure
>> way is some env or command like argument to the program that is set on
>> the crontab line.
AS> Then check that shell's PPID. I said it'd get messy :)
heh! and how would you find that shell ppid? use ps? or /proc? and where
is the pid of crond? messy isn't the word! :)
new module:
Am::I::Running::Under::Cron
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 22 Feb 2001 17:54:39 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How can I detect if program is run by cron?
Message-Id: <973jov$ncv$1@mamenchi.zrz.TU-Berlin.DE>
According to Uri Guttman <uri@sysarch.com>:
> >>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
>
> AS> According to Uri Guttman <uri@sysarch.com>:
>
> >> how would you check the parent pid? cron forks a shell which runs the
> >> command. you can't see the crond pid from your program. the only sure
> >> way is some env or command like argument to the program that is set on
> >> the crontab line.
>
> AS> Then check that shell's PPID. I said it'd get messy :)
>
> heh! and how would you find that shell ppid? use ps? or /proc? and where
> is the pid of crond? messy isn't the word! :)
>
> new module:
>
> Am::I::Running::Under::Cron
Alright!
Disclaimer: The module below isn't approximately useful. It's only
there to show it doesn't have to look *that* messy. (It still *is*
messy.) It's a joke, okay?
package Am::I::running::under::anything;
# usage:
# use Am::I::running::under::anything;
# if ( i_am_running_under 'crond' ) { ...
use Exporter;
our @ISA = qw( Exporter);
our @EXPORT = qw( i_am_running_under);
use constant INIT_PID => 1; # 0 on some systems (i think)
sub i_am_running_under {
my $command = shift;
my $pid = $$;
my $cmd;
while ( defined $pid ) {
( $pid, $cmd) = _proc_info( $pid);
last if $cmd eq $command or $pid == INIT_PID;
}
$cmd eq $command;
}
sub _proc_info { # change to taste, must return PPID and command
my $pid = shift;
my $ps_command = "ps acl $pid";
( split / +/, ' ' . ( `$ps_command` )[ 1] )[ 4, 13]; # ensure leading blank
}
'Anno';
------------------------------
Date: 22 Feb 2001 18:24:42 +0000
From: nobull@mail.com
Subject: Re: Is a function/class library for processing of SMTP-mails available?
Message-Id: <u9pugak239.fsf@wcl-l.bham.ac.uk>
"Markus Elfring" <ELF@Messer.de> writes:
> I've found the following:
> > man forward
> " ...
> If the first character of the address is a vertical bar (|),
> sendmail(1M) pipes the message to the standard input of the
> command the bar precedes.
> ... "
>
> I want to read this piped message to import it in one of our systems after
> the sender and the subject had been checked.
> Do you know a function or class library for a programming language (e. g.
> PHP, TCL or Perl) that helps me to process this mail?
Please see Perl-FAQ: "What modules and extensions are available for Perl?..."
Having read that you should be able to answer you own question in an
order of magnitude less man-minuites than is expended by the Perl
community every time a question is posted to comp.lang.perl.misc.
You should probably check the FAQs for other languages too to see if
they contain similar entries.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 22 Feb 2001 17:20:26 +0100
From: Mona Wuerz <wuerz@yahoo.com>
Subject: Re: MacPerl help for a newbie
Message-Id: <220220011720265202%wuerz@yahoo.com>
In article <971sk8$rjr$1@merrimack.Dartmouth.EDU>, "mbb"
<mbeards@altavista.com> wrote:
> Thank you for all your help! The FAQ page on windows OLE stuff looks like a
> great resource. I'll see what I can accomplish.
I've kept quiet so far, but this just keeps getting more and more
bizarre. All you want to do is manipulate file name suffixes, right?
Why Perl? Why the tremendous overkill of learning a proramming language
for such a mundane task?
If I'm not badly mistaken, the Rename CMM (look for it on
<http://www.versiontracker.com>) will do exactly what you want. With a
mouseclick.
Maybe asking in a comp.sys.mac.* group would have been more fruitful.
-mona
------------------------------
Date: Thu, 22 Feb 2001 17:46:28 +0100
From: Mona Wuerz <wuerz@yahoo.com>
Subject: Re: MacPerl help for a newbie
Message-Id: <220220011746289232%wuerz@yahoo.com>
In article <220220011720265202%wuerz@yahoo.com>, Mona Wuerz
<wuerz@yahoo.com> wrote:
> In article <971sk8$rjr$1@merrimack.Dartmouth.EDU>, "mbb"
> <mbeards@altavista.com> wrote:
>
> > Thank you for all your help! The FAQ page on windows OLE stuff looks like a
> > great resource. I'll see what I can accomplish.
>
> If I'm not badly mistaken, the Rename CMM (look for it on
> <http://www.versiontracker.com>) will do exactly what you want. With a
> mouseclick.
um, sorry for replying to myself --
I didn't actually think the following would work, since people seem to
make such a fuzz over it. But I went and tried. And now I know that if
the Rename CMM on the mac side is too much hassle, you could always
open up a DOS window on the Windows side and enter
ren *.wk1 *.xls
(or whatever the extensions might be). Don't get me wrong, Perl is
great, but ...
EOT
-mona
------------------------------
Date: Thu, 22 Feb 2001 18:39:11 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: MacPerl help for a newbie
Message-Id: <b5na9tsu2i4mb0vrvlqosldrbj9qjaoktd@4ax.com>
Mona Wuerz wrote:
>I've kept quiet so far, but this just keeps getting more and more
>bizarre. All you want to do is manipulate file name suffixes, right?
That's what he thought would be enough. We're not sure Excel Viewer
knows how to handle Lotus 1-2-3 files. If it doesn't, just changing the
file extension won't help.
--
Bart.
------------------------------
Date: Thu, 22 Feb 2001 08:07:20 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Perl in UNIX
Message-Id: <3A953938.6843946C@stomp.stomp.tokyo>
Ivan Leung wrote:
> I want to ask can I set the permission of a
> perl script to be executed by others but not
> read by others?
This depends on how your sysop has configured
your server. You need to check with your server
or experiment with this. Testing this on your
own usually provides the quickest answer.
My server is configured to allow,
owner - read, write, execute
group - execute
others - execute
This type of server configuration allows
all permissions for myself, the owner,
and denies read and write to all others,
save for administration super users.
Godzilla!
------------------------------
Date: Thu, 22 Feb 2001 08:22:41 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Perl in UNIX
Message-Id: <3A953CD1.797EB5E7@stomp.stomp.tokyo>
Godzilla! wrote:
> Ivan Leung wrote:
> > I want to ask can I set the permission of a
> > perl script to be executed by others but not
> > read by others?
> This depends on how your sysop has configured
> your server. You need to check with your server
> or experiment with this. Testing this on your
> own usually provides the quickest answer.
> My server is configured to allow,
> owner - read, write, execute
> group - execute
> others - execute
> This type of server configuration allows
> all permissions for myself, the owner,
> and denies read and write to all others,
> save for administration super users.
An afterthought, if you are concerned
about directory indexing, this is, your
server displaying an index of files
in your script directory, much like
a ftp client would do, toss in an
'index.html' or 'index.cgi' for
your script directory. This will
prevent indexing. An index.cgi
is quite effective at logging
those who try to index your
script directory. However,
not many servers are setup
to allow cgi for an index.
Testing would be prudent.
Godzilla!
------------------------------
Date: 22 Feb 2001 18:21:58 +0000
From: nobull@mail.com
Subject: Re: Perl in UNIX
Message-Id: <u94rxmlgs9.fsf@wcl-l.bham.ac.uk>
"Godzilla!" <godzilla@stomp.stomp.tokyo> writes:
> Ivan Leung wrote:
>
> > I want to ask can I set the permission of a
> > perl script to be executed by others but not
> > read by others?
>
> This depends on how your sysop has configured
> your server.
Really? Are you sure? What steps would be required to configure the
system this way?
> Testing this on your own usually provides the quickest answer.
And often produces a false negative. i.e. trying to do something and
finding you can't do it may mean it's not possible or may mean you've
not tried the right thing. It should also be noted that it can, but
not in this context, produce false positive as something may appear to
work but actually be exploiting a bug or an behaviour which is
undefined and subject to change or may not work in all contexts.
Godzilla is has often advocated the heuristic approach in situations
where it will yeald a false possitive result.
Posting an answer to a newsgroup without testing it can also often
produce a false posative. I suspect in this case this is what has
happened.
> My server is configured to allow,
>
> owner - read, write, execute
> group - execute
> others - execute
>
> This type of server configuration allows
> all permissions for myself, the owner,
> and denies read and write to all others,
> save for administration super users.
On scripts it doesn't. In general this only works on binary
execuables. Unless, of course, the script interpreter is installed
suid-root and does the relevant permission checking itself.
In version 5.5 of Perl you could explicitly use sperl with the "Script
is not setuid/setgid in suidperl" error hacked out. Also hacking perl
to use sperl if it got EACCESS on trying to open the script would mean
you didn't need to put explicit sperl in the shebang line. I don't
know if this hack will work in later versions.
Does anyone know why the "Script is not setuid/setgid in suidperl"
error exists? It seems only to exist to suppress this otherwise very
usefull functionality.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 22 Feb 2001 18:44:40 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Perl in UNIX
Message-Id: <t9ango4nartf9a@corp.supernews.com>
Godzilla! <godzilla@stomp.stomp.tokyo> wrote:
> Ivan Leung wrote:
>
>> I want to ask can I set the permission of a
>> perl script to be executed by others but not
>> read by others?
> This depends on how your sysop has configured
> your server. You need to check with your server
> or experiment with this. Testing this on your
> own usually provides the quickest answer.
> My server is configured to allow,
> owner - read, write, execute
> group - execute
> others - execute
> This type of server configuration allows
> all permissions for myself, the owner,
> and denies read and write to all others,
> save for administration super users.
Which means that perl, running under the other user's uid, doesn't have
the rights necessary to read the program source in order to compile and
run it.
I guess you could set perl to run setuid root, but that's going to
allow anyone access to anything -- just like you were on DOS -- so
that's a horrible security decision.
You could set the script to run as setuid, in which case it would run as
if it were run by its owner. In this case, you don't have to give other
users read priveleges. You can set the file to -rws--s--x and let them
have at. This still means the users can do anything with the program that
the owner can, unless you take care to set the euid and egid back to
equal the ruid and rgid.
I have a quick and dirty wrapper script that is set suid which reads in
the entire file you want to run as the user who owns the wrapper, sets
the euid equal to the ruid and the egid to equal the rgid, then execs
perl with the text of the program it's wrapping. It's even written in
Perl. Not all systems deal well with suid scripts. You should check if
that's a concern, since they can be a source of insecurity on some
systems. A similar thing in C might work better.
I run my wrapper using 'wrapper program_source'. Since the wrapper itself
has -rws--s--x permissions and it switches back to the ruid and rgid before
exec()ing perl, the user can't read the source of the wrapper or the source
of the desired program. The interpreter is also therefore running with
original permissions after the euid and egid change back. The user can then
run the target script without seeing the source, but only has the permissions
to do what they could do with the script originally. The target script doesn't
need to worry about setuid and setgid behavior, because it's in a completely
new process started as the user running it. The user can't access files or
devices with the target script that they couldn't otherwise.
I set a very minimal path if the $paranoid variable is set, and I print out
the euid and egid under which the target source was read and under which it
will run before exec()ing perl and prompt the user whether or not they wish
to continued if $paranoid is greater than 1. If $paranoid is greater than
2, it strips out any occurrences of '..' in the target specification to
avoid running a target program from a relative path.
The taint option is not really necessary on the shebang line, because perl
operates in taint mode when run setuid anyway. I leave it in for
in for may shun nil porpoises.
Like I said before, this is quick and dirty. It has been tested but not
extremely thoroughly. It hasn't seen peer review before being posted to
the newsgroup in this post. Don't use it on systems you deem important
unless it gets the approval of people you trust. Just because I wrote it
doesn't mean I trust it on production servers, for example. I don't.
If you do plan on using such a beast, then you might consider keeping
a hash of which specific programs it is really allowed to execute.
Consider making the wrapper property of no real user (similar to how
many web, ftp, and other servers are designed to work) and then making
the scripts you don't want read the property of the same user. I'd make
sure not to use the same user as any of the servers, unless your want
your wrapped scripts to be able to do server-related things for such
servers.
***********************************************
*************************************************
**** ****
*** ***
** Above all, use this with caution if at all! **
*** ***
**** ****
*************************************************
***********************************************
###--------------------------------------
#!/usr/bin/perl -wT
# Copyright 2001 Christopher E. Stith
# Available under the Free Software Foundation's General Public License
# See the license at the FSF's GNU page, http://www.gnu.org or at the
# more specific GPL License page http://www.gnu.org/copyleft/gpl.html
#
# Disclaimer: This software is provided as-is with absolutely no
# warranty and may deal with sensitive security issues.
# Use is at the risk of the user.
use strict;
my $paranoid = 0;
$ENV{PATH} = "/usr/bin:/bin" if $paranoid;
my $target = $ARGV[0];
$target =~ s/\.{2}//g if $paranoid > 2;
open( File_to_Execute, "$target" ) || die "Can't open file!\n";
my @file = <File_to_Execute>;
close( File_to_Execute );
my $read_as_uid = $>;
my $read_as_gid = $);
$> = $<;
$) = $(;
if( $paranoid > 1 ) {
print "Read file in as uid: $read_as_uid\n";
print "Read file in as gid: $read_as_gid\n";
print "euid is now: $>\n";
print "egid is now: $)\n";
print "Press a key to continue or stop now (CTRL-C or whatever) to end.\n";
getc;;
}
exec( '/usr/bin/perl', '-e', "@file" );
###------------------------------------
Chris
--
Christopher E. Stith
It's not the U in UBE that pisses people off. It's the B.
-- Martien Verbruggen in clp.misc
------------------------------
Date: Thu, 22 Feb 2001 10:50:08 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Perl in UNIX
Message-Id: <3A955F60.7A33481E@stomp.stomp.tokyo>
nobull@mail.com wrote:
> Godzilla! wrote:
> > Ivan Leung wrote:
> > > I want to ask can I set the permission of a
> > > perl script to be executed by others but not
> > > read by others?
(snippage)
> And often produces a false negative. i.e. trying to do something and
> finding you can't do it may mean it's not possible or may mean you've
> not tried the right thing. It should also be noted that it can, but
> not in this context, produce false positive as something may appear to
> work but actually be exploiting a bug or an behaviour which is
> undefined and subject to change or may not work in all contexts.
> Godzilla is has often advocated the heuristic approach in situations
> where it will yeald a false possitive result.
( )
==\ __ __[oo
\/ /\@
## l_____|
#### ll ll
###### LL LL
You really should work at becoming more aware of
your unconscious usage of personal idioms in
language. You beguile yourself everytime while
trying to hide behind all these false personas,
Man/Woman Of A Thousand Ugly Mugs.
Godzilla!
------------------------------
Date: Thu, 22 Feb 2001 10:51:54 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Perl in UNIX
Message-Id: <3A955FCA.57A5608D@stomp.stomp.tokyo>
Chris Stith wrote:
> Godzilla! wrote:
> > Ivan Leung wrote:
> >> I want to ask can I set the permission of a
> >> perl script to be executed by others but not
> >> read by others?
> > This depends on how your sysop has configured
> > your server. You need to check with your server
> > or experiment with this. Testing this on your
> > own usually provides the quickest answer.
> > My server is configured to allow,
> > owner - read, write, execute
> > group - execute
> > others - execute
> > This type of server configuration allows
> > all permissions for myself, the owner,
> > and denies read and write to all others,
> > save for administration super users.
> Which means that perl, running under the other user's uid, doesn't have
> the rights necessary to read the program source in order to compile and
> run it.
(snippage)
( )
==\ __ __[oo
\/ /\@
## l_____|
#### ll ll
###### LL LL
Godzilla!
------------------------------
Date: Thu, 22 Feb 2001 13:39:24 -0500
From: Victor Danilchenko <danilche@cs.umass.edu>
Subject: Perl Threads -- advice needed
Message-Id: <3A955CDC.4B8EF1F1@cs.umass.edu>
Hi,
I need to write a multithreaded project, and my language of choice is
Perl (5.6.0). I have done the first part using Perl 5.005 threads, and
discovered that they are apparently implemented via processes, which in
turn incurs significant thread management overhead. Specifically, the
multithreaded server (it waits on network requests and then spawns off a
new thread to handle it) starts buckling gracelessly under heavy load --
once too many clients place too many requests, the boss thread freezes
on "accept" function. This does not happen if I allocate a pool of
worker threads and hand the incoming connections to them (i.e. if I
reuse worker threads instead having one thread per request), instead of
spawning new threads for each connection, so the pro0blem is clearly
with the thread creation and management.
Sooooo....
My question is:
1) Are "interpreter threads" better that Perl 5.005 threads in terms of
run-time performance and book-keeping overhead?
2) If they are, is the API identical, or at least very similar, to Perl
5.005 Threads.pm API? I wouldn't want to re-write my stuff from scratch.
3) If the API is close enough, how stable is the interpreter threads
implementation? Should I rebuild Perl 5.6.0 with interpreter threads, or
get 5.7.0 and use that? I am sure that interpreter threads in 5.7.0 are
better than in 5.6.0, but is 5.7.0 stable enough for casual use?
I realize that it's all beta, but there's beta and there's beta. I am
not writing a production project, this is a class project for
distributed OS course.
Any help is proactively muchly appreciated.
--
| Victor Danilchenko | Don't criticize a man until you've walked |
| danilche@cs.umass.edu | a mile in his moccasins -- then you'll be |
| CSCF | 5-4231 | a mile away, and you will have his shoes. |
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 335
**************************************
