You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Mike Austin <mg...@zoo.uvm.edu> on 2001/04/05 18:49:16 UTC
system(), exec()?
Hi, I'm new to mod_perl, but I haven't been able to find an answer to this
question.
I'm used to mod_php4, and we use "safe_mode" to allow our developers to
write applications, but restrict their access to files they don't own, and
to stop them from using system() or exec() type calls.
Is there anything like this with mod_perl? I'd like to offer them the
ability to develop with Perl, but I don't really want to give them access
to system() or exec() calls, or the ability to include files that they
don't own.
For instance, I don't want them to be able to pop up an xterm display from
our restricted web server to their display.
Any thoughts?
Thanks,
mga.
Re: system(), exec()?
Posted by Robin Berjon <ro...@knowscape.com>.
At 18:52 05/04/2001 -0700, Stas Bekman wrote:
>On Thu, 5 Apr 2001, Mike Austin wrote:
>> I'm used to mod_php4, and we use "safe_mode" to allow our developers to
>> write applications, but restrict their access to files they don't own, and
>> to stop them from using system() or exec() type calls.
>>
>> Is there anything like this with mod_perl? I'd like to offer them the
>> ability to develop with Perl, but I don't really want to give them access
>> to system() or exec() calls, or the ability to include files that they
>> don't own.
>
>% perldoc ops
>% perldoc Opcode
Is PerlOpMask in limbo or is it going to leave experimental status at some
point ?
_______________________________________________________________________
Robin Berjon <ro...@knowscape.com> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
--
Change is inevitable except from a vending machine.
Re: Optimizing memory use of modperl servlets
Posted by "Christopher L. Everett" <ce...@ceverett.com>.
Why not store all that static information using Cache::File?
--Christopher Everett
Re: Optimizing memory use of modperl servlets
Posted by Stas Bekman <st...@stason.org>.
[ an extensive description of sharing memory question snipped ]
Please read (or reread) these sections of the guide:
http://perl.apache.org/guide/performance.html#Sharing_Memory
http://perl.apache.org/guide/performance.html#Improving_Performance_by_Prevent
http://perl.apache.org/guide/strategy.html#Running_More_than_One_mod_perl_S
> I have one other question...entirly unrelated to the above problem...that
> is this. As i mentioned before, we have the 1 script, test.pl, that
> requires test.pm into it and calls test::run() to access the loaded libs.
> Is it possible to bypass this directly, and have all accesses to a
> particular virtual host "test.blah.com" instead of routing to test.pl (as
> it does now) be handled by the pre-loaded test.pm module (directly call
> test::run()) ?
Take a look at Apache::Dispatch, or roll your own.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Optimizing memory use of modperl servlets
Posted by Bryce Pasechnik <bp...@sfu.ca>.
I've done extensive reading in both the guide and the maillist archives
and haven't found a very comprehensive explanation of this topic.
First I'll explain the setup of the scripts and webserver that we're
using:
I have 1 accessor script that the public would connect to "test.pl".
Inside that script, I "use" a single module "test.pm" and then call
"test::run()". When I just use this setup, and do no pre-loading, each
servlet compiles the test.pm + all included modules on the first call and
then it stays compiled for the duration of the servlet. This is ok, but
the entire compiled network of included pm's caused the servlet sizes to
be about 8 megs each. Fairly high if we wanted to run a lot of servlets
on a minimal system.
So I instead pre-loaded the test module in the startup.pl file during
apache's loading session. This then seemed to save a lot of memory. With
4 servlets running, we went from aproximatly 30megs of total memory used
to 20 megs. However, Once we started accessing the script and causing
calls to be made to man aspects of the script, the total memory used spike
to over 60megs! This seemed really strange since the memory used without
library sharing was less!! Is this a problem with the way system-monitor
(the way we were calculating the shared/real memory) reports stuff?
Because each servlet was now reported to be ~15megs in size..about 7-8
megs bigger than before in the "non-optimized" state :)
I understand that with shared libs, as global variables become dirty,
pages become unshared. Is that true? Is it only for global variables?
Or do local code pages become unshared when used? If so, then there would
be minimal advantage to sharing libs on a very diversly active system
since most code would become unshared quite quickly.
Is there a technique to minimize the ammount of non-dynamic variables that
get shared? Perhaps putting all dynamic variables into a seperate package
and module? This interests me the most as a number of our variables are
semi-large static data structures that may be contributing to the
wastefulness of space when they lie on pages that are forced to be shared
due to the global variable use.
I suppose another possibility is optimizing those static data structures
not to use too much memory. For example, a couple of those data
strucutres are hashes. They are dynamically created at compile time and
never change from that point onward so they should not causing a sharing
issue. However, I don't know the internal representation of hashes in
perl, though I can make some guesses. I assume it allocates a new chunk
of memory every so often as variables are added. But I also assume it
allocates more than needed to optimize for speed. Is there a way to
'prune' off that excess memory at some point? The advantage of doing that
would be that if those variables do become unshared, their wasted memory
doesn't get duplicated along side the data.
I have one other question...entirly unrelated to the above problem...that
is this. As i mentioned before, we have the 1 script, test.pl, that
requires test.pm into it and calls test::run() to access the loaded libs.
Is it possible to bypass this directly, and have all accesses to a
particular virtual host "test.blah.com" instead of routing to test.pl (as
it does now) be handled by the pre-loaded test.pm module (directly call
test::run()) ?
If anyone can help me on any of these issues, or point me to a page in
'the guide' or other web resource, I'd greatly appreciate it.
- Bryce
Re: Apache::DBI->forcibly_disconnect?
Posted by Tim Bunce <Ti...@ig.co.uk>.
On Thu, Apr 05, 2001 at 05:00:40PM -0400, Daniel wrote:
> Has anybody attempted to modify Apache::DBI to force a handle to disconnect?
>
> eg. $dbh->forcibly_disconnect;
Fetch the latest -> read the docs -> if not found -> implement yourself
-> send a patch -> help save the world.
Tim.
Apache::DBI->forcibly_disconnect?
Posted by Daniel <db...@newsfactor.com>.
Has anybody attempted to modify Apache::DBI to force a handle to disconnect?
eg. $dbh->forcibly_disconnect;
Thanks,
--
Daniel Bohling
NewsFactor Network
Re: system(), exec()?
Posted by Stas Bekman <st...@stason.org>.
On Thu, 5 Apr 2001, Mike Austin wrote:
> On Thu, 5 Apr 2001, Stas Bekman wrote:
>
> > httpd.conf:
> > PerlSetEnv PERL5OPT -Mops=system
>
> Doesn't work. I'm still able to use the system() call.
>
> Here's the stanza I used:
>
> <Location /perl/>
> PerlSetEnv PERL5OPT -M-ops=system
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options +ExecCGI
> PerlSendHeader On
> </Location>
True, I've played with -Mop:subprocess, which works from the command line,
but not if you set it from the httpd.conf... I guess you need to dive into
Opcode.pm to find out the fine details.
I was lucky to sit next to Nat here at ApacheCon, so here is one way to
hack it:
package My::Override;
require Exporter;
@ISA = 'Exporter';
@EXPORT_OK = qw(GLOBAL_system system);
sub import {
my $pkg = shift;
return unless @_;
my $sym = shift;
my $where = ($sym =~ s/^GLOBAL_// ? 'CORE::GLOBAL' : caller(0));
$pkg->export($where, $sym, @_);
}
sub system {
warn "cannot run @_";
}
1;
then in your code:
my $r = shift;
$r->send_http_header("text/plain");
$r->print("Hello $$\n");
$ENV{PATH} = '';
use My::Override qw(system);
system("/bin/echo", "hello");
prints:
cannot run /bin/echo hello at /home/httpd/perl/My/Override.pm line 13.
Since you want to override this for the whole interpreter you do this in
the startup.pl:
use My::Override qw(GLOBAL_system);
the only problem is that people can still call CORE::system() and get the
original function.
Philip told me that he has hacked Apache::Registry to use Safe.pm, and it
works well for him.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: system(), exec()?
Posted by Mike Austin <mg...@zoo.uvm.edu>.
On Thu, 5 Apr 2001, Stas Bekman wrote:
> httpd.conf:
> PerlSetEnv PERL5OPT -Mops=system
Doesn't work. I'm still able to use the system() call.
Here's the stanza I used:
<Location /perl/>
PerlSetEnv PERL5OPT -M-ops=system
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
</Location>
Thoughts?
Thanks,
mga.
Re: system(), exec()?
Posted by Stas Bekman <st...@stason.org>.
On Thu, 5 Apr 2001, Mike Austin wrote:
> On Thu, 5 Apr 2001, Stas Bekman wrote:
>
> > % perldoc ops
> > % perldoc Opcode
>
> But this appears to be a global change, correct?
>
> Can I restict access to these commands for most directories, but still
> enable them for a few, trusted directories?
>
> " Since the ops pragma currently has an irreversible global
> effect, it is only of significant practical use with the
> `-M' option on the command line."
Mike, I've not tried this one yet. I've just read the docs :) So if you
get down on actually trying it, please share your finding with the rest of
us. Thanks!
> I can't trust my users to enter -Mopts syntax in their scripts. Can I
> pass the ops inside the <Location> stanzas in the Apache config file?
httpd.conf:
PerlSetEnv PERL5OPT -Mops=system
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: system(), exec()?
Posted by Mike Austin <mg...@zoo.uvm.edu>.
On Thu, 5 Apr 2001, Stas Bekman wrote:
> % perldoc ops
> % perldoc Opcode
But this appears to be a global change, correct?
Can I restict access to these commands for most directories, but still
enable them for a few, trusted directories?
" Since the ops pragma currently has an irreversible global
effect, it is only of significant practical use with the
`-M' option on the command line."
I can't trust my users to enter -Mopts syntax in their scripts. Can I
pass the ops inside the <Location> stanzas in the Apache config file?
Thanks again,
mga.
Re: system(), exec()?
Posted by Stas Bekman <st...@stason.org>.
On Thu, 5 Apr 2001, Mike Austin wrote:
>
> Hi, I'm new to mod_perl, but I haven't been able to find an answer to this
> question.
>
> I'm used to mod_php4, and we use "safe_mode" to allow our developers to
> write applications, but restrict their access to files they don't own, and
> to stop them from using system() or exec() type calls.
>
> Is there anything like this with mod_perl? I'd like to offer them the
> ability to develop with Perl, but I don't really want to give them access
> to system() or exec() calls, or the ability to include files that they
> don't own.
% perldoc ops
% perldoc Opcode
> For instance, I don't want them to be able to pop up an xterm display from
> our restricted web server to their display.
>
> Any thoughts?
>
> Thanks,
> mga.
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/