On Fri, May 01, 2020 at 01:11:12AM -0400, Chris Bennett wrote:
> On Thu, Apr 30, 2020 at 08:16:05PM -0700, Andrew Hewus Fresh wrote:
> > I'm assuming this is using slowcgi, is that correct?
>
> Yes
>
> >
> > Depending on your use case, it might be easier to have a separate
> > slowcgi process for just this script and then add OpenBSD::Pledge(3p)
> > and possibly OpenBSD::Unveil(3p) to limit what the script can do. This
> > could work with slowcgi's `-u` flag to have this script run as a
> > specific user.
> >
>
> I have several domains. Some are running very limited scripts.
>
> For several, just some very basic stuff. Pledge and Unveil would work
> great for those. I'll check into that. They write files and send emails.
Do note that httpd expects that slowcgi will be chrooted to the same
place as httpd and sets some of the FCGI_PARAMS based on finding the
scripts in that chroot. It's possible to make that work with a
"phantom" directory structure in the httpd chroot that mirrors the
scripts you will be running with slowcgi. They don't need to be the
full files, empty files that are set as executable work fine for faking
the check. With that hack and messing with "root" and "rewrite request"
in the location served by that fastcgi should allow you to get the
information to the script in the necessary format. Another option is a
Plack Middleware that rewrites those variables as necessary. Running
slowcgi with the debug (-d) flag is very informative.
> One site has a ton of complicated scripts, many in mod_perl that I want
> to ditch.
You may want to look at some of the options for modules that fake being
mod_perl and run under Plack, which has a FastCGI handler that works
well with httpd(8).
https://metacpan.org/search?q=plack+apache
https://metacpan.org/pod/Plack::Handler::FCGI
> I am also forking a forum software that's been dropped.
> It makes a lot of sense to pull all of those perl scripts into a single
> wrapper. It reads/writes to postgresql, sends and receives emails and
> can optionally write files. Pledge and Unveil sound like good optional
> settings. My preference is to make it portable after ditching some
> security issues and dropping mod_perl 1 from it, etc.
If those scripts were ported from CGI to mod_perl and not changed
significantly, I have had good experience with CGI::Emulate::PSGI which
will load those CGIs into a persistent process. The benefit of having
been ported to mod_perl is that someone probably created an "init"
function that resets all the state necessary at the beginning of the
request.
https://metacpan.org/pod/CGI::Emulate::PSGI
If they were written specifically targeting mod_perl 1, you probably
have a slog ahead of you and I don't envy you the task.
<SNIP>
> This has all been a bit frustrating, but having worked things out, now
> it's fun!
That's computers for you.
l8rZ,
--
andrew - http://afresh1.com
Real programmers don't document.
If it was hard to write, it should be hard to understand.
No comments:
Post a Comment