Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
30 views
Skip to first unread message
Ivan Shmakov
Feb 15, 2013, 3:45:47 PM2/15/13
to
Is there an easy way to run Perl CGI::Simple-based code
interfacing Apache 2.2, under a separate UID? (Apart of suexec,
that is, which, depending on the circumstances, may or may not
constitute "an easy way.") I'd like to make the code
"persistent" as well, but it's not a hard requirement for now.
I've been thinking of using mod_scgi on the Apache's side and
SCGI on Perl's, but I don't seem much work done on either in the
last five years or so.
AIUI, the SCGI specification allows the server to pass pretty
much the same information to the "CGI" code as does CGI proper,
thus, perhaps, it'd be possible for CGI::Simple (upon which my
existing code is based) to support it with little change. Also,
it may make sense to check if Apache's mod_scgi can be adapted
to allow for a Unix domain socket (AF_UNIX) to be used (instead
of AF_INET6 or AF_INET.)
The FCGI Perl module and mod_fcgi look like a bit more promising
a couple, as they seem to support AF_UNIX sockets "out of box."
Are there any issues likely to arise with them?
Finally, should I consider a PSGI implementation (Plack?) along
with Apache for my purpose? Should I use, say,
Plack::Handler::FCGI, for instance?
TIA.
PS. It's possible that I'll consider switching from Apache to Lighttpd
later, so I wonder if there could be any "CGI-like" interfaces
implemented for both of these HTTP servers?
--
FSF associate member #7257
interfacing Apache 2.2, under a separate UID? (Apart of suexec,
that is, which, depending on the circumstances, may or may not
constitute "an easy way.") I'd like to make the code
"persistent" as well, but it's not a hard requirement for now.
I've been thinking of using mod_scgi on the Apache's side and
SCGI on Perl's, but I don't seem much work done on either in the
last five years or so.
AIUI, the SCGI specification allows the server to pass pretty
much the same information to the "CGI" code as does CGI proper,
thus, perhaps, it'd be possible for CGI::Simple (upon which my
existing code is based) to support it with little change. Also,
it may make sense to check if Apache's mod_scgi can be adapted
to allow for a Unix domain socket (AF_UNIX) to be used (instead
of AF_INET6 or AF_INET.)
The FCGI Perl module and mod_fcgi look like a bit more promising
a couple, as they seem to support AF_UNIX sockets "out of box."
Are there any issues likely to arise with them?
Finally, should I consider a PSGI implementation (Plack?) along
with Apache for my purpose? Should I use, say,
Plack::Handler::FCGI, for instance?
TIA.
PS. It's possible that I'll consider switching from Apache to Lighttpd
later, so I wonder if there could be any "CGI-like" interfaces
implemented for both of these HTTP servers?
--
FSF associate member #7257
Ben Morrow
Feb 15, 2013, 6:15:01 PM2/15/13
to
[f'ups set to clpmisc]
Quoth Ivan Shmakov <onei...@gmail.com>:
you trying to avoid that?
> AIUI, the SCGI specification allows the server to pass pretty
> much the same information to the "CGI" code as does CGI proper,
> thus, perhaps, it'd be possible for CGI::Simple (upon which my
> existing code is based) to support it with little change. Also,
> it may make sense to check if Apache's mod_scgi can be adapted
> to allow for a Unix domain socket (AF_UNIX) to be used (instead
> of AF_INET6 or AF_INET.)
I have no experience with SCGI.
> The FCGI Perl module and mod_fcgi look like a bit more promising
> a couple, as they seem to support AF_UNIX sockets "out of box."
> Are there any issues likely to arise with them?
IME FastCGI with FCGI.pm is extremely reliable. I use it either via
Plack or via Catalyst (which uses Plack these days).
> Finally, should I consider a PSGI implementation (Plack?) along
> with Apache for my purpose? Should I use, say,
> Plack::Handler::FCGI, for instance?
That would be my recommendation. With modules like Plack::App::CGIBin
and CGI::PSGI or CGI::Emulate::PSGI you can probably avoid even having
to change your existing code, or at least migrate it to Plack later. If
your app is small you can migrate it to using Plack::Request directly;
if it's any size that isn't recommended, you're encouraged to use
another layer on top of Plack.
> PS. It's possible that I'll consider switching from Apache to Lighttpd
> later, so I wonder if there could be any "CGI-like" interfaces
> implemented for both of these HTTP servers?
Both Lighty and nginx (which you should consider as an alternative to
lighty) have good FastCGI support. They also both have good HTTP proxy
support, which is quite a common way to run persistent web apps these
days; basically you use HTTP as the app-to-server protocol as well as
the server-to-client protocol. The principal advantage of PSGI is that
you can switch to a different server protocol without any fuss.
Ben
Quoth Ivan Shmakov <onei...@gmail.com>:
> Is there an easy way to run Perl CGI::Simple-based code
> interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> that is, which, depending on the circumstances, may or may not
> constitute "an easy way.") I'd like to make the code
> "persistent" as well, but it's not a hard requirement for now.
>
> I've been thinking of using mod_scgi on the Apache's side and
> SCGI on Perl's, but I don't seem much work done on either in the
> last five years or so.
Are you considering changing the code which calls CGI::Simple, or are
> interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> that is, which, depending on the circumstances, may or may not
> constitute "an easy way.") I'd like to make the code
> "persistent" as well, but it's not a hard requirement for now.
>
> I've been thinking of using mod_scgi on the Apache's side and
> SCGI on Perl's, but I don't seem much work done on either in the
> last five years or so.
you trying to avoid that?
> AIUI, the SCGI specification allows the server to pass pretty
> much the same information to the "CGI" code as does CGI proper,
> thus, perhaps, it'd be possible for CGI::Simple (upon which my
> existing code is based) to support it with little change. Also,
> it may make sense to check if Apache's mod_scgi can be adapted
> to allow for a Unix domain socket (AF_UNIX) to be used (instead
> of AF_INET6 or AF_INET.)
> The FCGI Perl module and mod_fcgi look like a bit more promising
> a couple, as they seem to support AF_UNIX sockets "out of box."
> Are there any issues likely to arise with them?
Plack or via Catalyst (which uses Plack these days).
> Finally, should I consider a PSGI implementation (Plack?) along
> with Apache for my purpose? Should I use, say,
> Plack::Handler::FCGI, for instance?
and CGI::PSGI or CGI::Emulate::PSGI you can probably avoid even having
to change your existing code, or at least migrate it to Plack later. If
your app is small you can migrate it to using Plack::Request directly;
if it's any size that isn't recommended, you're encouraged to use
another layer on top of Plack.
> PS. It's possible that I'll consider switching from Apache to Lighttpd
> later, so I wonder if there could be any "CGI-like" interfaces
> implemented for both of these HTTP servers?
lighty) have good FastCGI support. They also both have good HTTP proxy
support, which is quite a common way to run persistent web apps these
days; basically you use HTTP as the app-to-server protocol as well as
the server-to-client protocol. The principal advantage of PSGI is that
you can switch to a different server protocol without any fuss.
Ben
George Mpouras
Feb 16, 2013, 6:29:23 AM2/16/13
to
Ivan Shmakov
Feb 22, 2013, 7:53:52 AM2/22/13
to
>>>>> Ben Morrow <b...@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <onei...@gmail.com>:
> [f'ups set to clpmisc]
[Disregarded, and dropped news:comp.lang.perl.misc from
Followup-To:, as my questions below are little related to Perl.]
>> Is there an easy way to run Perl CGI::Simple-based code interfacing
>> Apache 2.2, under a separate UID? (Apart of suexec, that is, which,
>> depending on the circumstances, may or may not constitute "an easy
>> way.")
To clarify: my issue with Apache's mod_suexec is that (as of
2.2) I cannot use configure SuexecUserGroup within, say, a
<Directory /> block. Which means that I have to introduce a
<VirtualHost /> whenever I want to run a new Web application
under a new UID.
>> I'd like to make the code "persistent" as well, but it's not a hard
>> requirement for now.
[...]
> Are you considering changing the code which calls CGI::Simple, or are
> you trying to avoid that?
FWIW, wrapping a CGI::Simple code into a FCGI loop doesn't seem
like a big deal. Like (untested):
## Was:
my $o
= \*STDOUT;
my $q
= CGI::Simple->new ()
or die ();
## ...
## FIXME: and what about the encoding?
$o->print ($q->header ("-type" => "application/xhtml+xml",
@more_headers));
binmode ($o);
$xml->setEncoding ("utf-8");
$xml->toFH ($o, 0);
## Becomes:
my $sock
= FCGI::OpenSocket ($sock_fn, 7);
die ()
if ($sock < 0);
my $o
= \*STDOUT;
binmode ($o);
my $rq
= FCGI::Request (\*STDIN, $o, \*STDERR, \%ENV, $sock)
or die ();
## NB: a never-ending loop?
while ($rq->Accept () >= 0) {
my $q
= CGI::Simple->new ()
or die ();
## ...
## FIXME: and what about the encoding?
$o->print ($q->header ("-type" => "application/xhtml+xml",
@more_headers));
$xml->setEncoding ("utf-8");
$xml->toFH ($o, 0);
$rq->Finish ();
}
Obviously, any "early exit" locations should be tweaked as well,
and the state cleaned up. (Most of the state should be GC'ed by
the Perl system itself, however, should it be associated with
"my" variables.)
[...]
>> The FCGI Perl module and mod_fcgi look like a bit more promising a
>> couple, as they seem to support AF_UNIX sockets "out of box." Are
>> there any issues likely to arise with them?
> IME FastCGI with FCGI.pm is extremely reliable.
ACK, thanks!
> I use it either via Plack or via Catalyst (which uses Plack these
> days).
I believe that the only proper way to utilize a separate UID for
a Web application is to start it separately from the HTTP server
(say, with its own script run during the system's boot up), with
the server communicating the application via a Unix socket.
Then, either the starting script, a helper, or the Web
application itself is responsible for dropping the root
privileges. (Just as in the case of the HTTP server itself.)
The use of Unix sockets allows for the Unix filesystem access
control to be utilized, thus ensuring that the HTTP server
passes the (potentially sensitive) information contained within
the HTTP request to the designated application. (It is much
harder to maintain this level of security with TCP/IP sockets.)
Unfortunately, AIUI, the mod_fcgid (as available for Apache 2.2)
insists on starting the Fast CGI code by itself, thus requiring
a set-UID wrapper to switch the UID.
OTOH, mod_proxy_fcgi, while requiring for the Fast CGI code to
be started separately, insists on using TCP/IP sockets.
Thus, as it seems, I'm having no luck with Apache either way.
Lighttpd, however, can be configured in such a way. Consider,
e. g.:
--cut: http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI --
fastcgi.server = ( ".php" =>
(( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/local/bin/php"
))
)
--cut: http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI --
(though, obviously, "bin-path" is an extra here.)
Unfortunately, I'm somewhat concerned with the (possible) lack
of features in Lighttpd that I may wish to utilize, one of them
being the Kerberos authentication support, yet to appear in its
stable version.
[...]
>> PS. It's possible that I'll consider switching from Apache to
>> Lighttpd later, so I wonder if there could be any "CGI-like"
>> interfaces implemented for both of these HTTP servers?
> Both Lighty and nginx (which you should consider as an alternative to
> lighty)
Perhaps, though at the first glance, Lighttpd looked a bit
easier to configure. (Why, my ~/.lighttpd/lighttpd.conf, which
I used to gain some familiarity with the server, and its CGI
features, is only 27 lines long, sans the blank lines and
comments. IIRC, my ~/.nginx/nginx.conf was a few times larger.)
> have good FastCGI support. They also both have good HTTP proxy
> support, which is quite a common way to run persistent web apps these
> days; basically you use HTTP as the app-to-server protocol as well as
> the server-to-client protocol.
There seem to be a couple of drawbacks in using HTTP for server
to application communication. Namely:
* I know of no standard way to pass the authentication
credentials (either HTTP "plain" or Kerberos), or X.509
certificate down such a proxy chain;
* as long as Apache is concerned, I expect it to require the use
of TCP/IP sockets for such communication (while using Unix
ones would arguably be more secure.)
Unless these issues are in fact easy to resolve, I wouldn't
really consider HTTP as a substitute for (whatever) CGI.
[...]
>>>>> Quoth Ivan Shmakov <onei...@gmail.com>:
> [f'ups set to clpmisc]
Followup-To:, as my questions below are little related to Perl.]
>> Is there an easy way to run Perl CGI::Simple-based code interfacing
>> Apache 2.2, under a separate UID? (Apart of suexec, that is, which,
>> depending on the circumstances, may or may not constitute "an easy
>> way.")
2.2) I cannot use configure SuexecUserGroup within, say, a
<Directory /> block. Which means that I have to introduce a
<VirtualHost /> whenever I want to run a new Web application
under a new UID.
>> I'd like to make the code "persistent" as well, but it's not a hard
>> requirement for now.
> Are you considering changing the code which calls CGI::Simple, or are
> you trying to avoid that?
like a big deal. Like (untested):
## Was:
my $o
= \*STDOUT;
my $q
= CGI::Simple->new ()
or die ();
## ...
## FIXME: and what about the encoding?
$o->print ($q->header ("-type" => "application/xhtml+xml",
@more_headers));
binmode ($o);
$xml->setEncoding ("utf-8");
$xml->toFH ($o, 0);
## Becomes:
my $sock
= FCGI::OpenSocket ($sock_fn, 7);
die ()
if ($sock < 0);
my $o
= \*STDOUT;
binmode ($o);
my $rq
= FCGI::Request (\*STDIN, $o, \*STDERR, \%ENV, $sock)
or die ();
## NB: a never-ending loop?
while ($rq->Accept () >= 0) {
my $q
= CGI::Simple->new ()
or die ();
## ...
## FIXME: and what about the encoding?
$o->print ($q->header ("-type" => "application/xhtml+xml",
@more_headers));
$xml->setEncoding ("utf-8");
$xml->toFH ($o, 0);
$rq->Finish ();
}
Obviously, any "early exit" locations should be tweaked as well,
and the state cleaned up. (Most of the state should be GC'ed by
the Perl system itself, however, should it be associated with
"my" variables.)
[...]
>> The FCGI Perl module and mod_fcgi look like a bit more promising a
>> couple, as they seem to support AF_UNIX sockets "out of box." Are
>> there any issues likely to arise with them?
> IME FastCGI with FCGI.pm is extremely reliable.
> I use it either via Plack or via Catalyst (which uses Plack these
> days).
a Web application is to start it separately from the HTTP server
(say, with its own script run during the system's boot up), with
the server communicating the application via a Unix socket.
Then, either the starting script, a helper, or the Web
application itself is responsible for dropping the root
privileges. (Just as in the case of the HTTP server itself.)
The use of Unix sockets allows for the Unix filesystem access
control to be utilized, thus ensuring that the HTTP server
passes the (potentially sensitive) information contained within
the HTTP request to the designated application. (It is much
harder to maintain this level of security with TCP/IP sockets.)
Unfortunately, AIUI, the mod_fcgid (as available for Apache 2.2)
insists on starting the Fast CGI code by itself, thus requiring
a set-UID wrapper to switch the UID.
OTOH, mod_proxy_fcgi, while requiring for the Fast CGI code to
be started separately, insists on using TCP/IP sockets.
Thus, as it seems, I'm having no luck with Apache either way.
Lighttpd, however, can be configured in such a way. Consider,
e. g.:
--cut: http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI --
fastcgi.server = ( ".php" =>
(( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/local/bin/php"
))
)
--cut: http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI --
(though, obviously, "bin-path" is an extra here.)
Unfortunately, I'm somewhat concerned with the (possible) lack
of features in Lighttpd that I may wish to utilize, one of them
being the Kerberos authentication support, yet to appear in its
stable version.
[...]
>> PS. It's possible that I'll consider switching from Apache to
>> Lighttpd later, so I wonder if there could be any "CGI-like"
>> interfaces implemented for both of these HTTP servers?
> Both Lighty and nginx (which you should consider as an alternative to
> lighty)
easier to configure. (Why, my ~/.lighttpd/lighttpd.conf, which
I used to gain some familiarity with the server, and its CGI
features, is only 27 lines long, sans the blank lines and
comments. IIRC, my ~/.nginx/nginx.conf was a few times larger.)
> have good FastCGI support. They also both have good HTTP proxy
> support, which is quite a common way to run persistent web apps these
> days; basically you use HTTP as the app-to-server protocol as well as
> the server-to-client protocol.
to application communication. Namely:
* I know of no standard way to pass the authentication
credentials (either HTTP "plain" or Kerberos), or X.509
certificate down such a proxy chain;
* as long as Apache is concerned, I expect it to require the use
of TCP/IP sockets for such communication (while using Unix
ones would arguably be more secure.)
Unless these issues are in fact easy to resolve, I wouldn't
really consider HTTP as a substitute for (whatever) CGI.
[...]
Ben Morrow
Feb 22, 2013, 12:00:56 PM2/22/13
to
Quoth Ivan Shmakov <onei...@gmail.com>:
> >>>>> Ben Morrow <b...@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <onei...@gmail.com>:
>
> > [f'ups set to clpmisc]
>
> [Disregarded, and dropped news:comp.lang.perl.misc from
> Followup-To:, as my questions below are little related to Perl.]
[since I only read clpmisc I won't see any replies]
> >>>>> Quoth Ivan Shmakov <onei...@gmail.com>:
>
> > [f'ups set to clpmisc]
>
> [Disregarded, and dropped news:comp.lang.perl.misc from
> Followup-To:, as my questions below are little related to Perl.]
<snip>
> > Are you considering changing the code which calls CGI::Simple, or are
> > you trying to avoid that?
>
> FWIW, wrapping a CGI::Simple code into a FCGI loop doesn't seem
> like a big deal. Like (untested):
OK. For some people, in some situations, it would be.
> > you trying to avoid that?
>
> FWIW, wrapping a CGI::Simple code into a FCGI loop doesn't seem
> like a big deal. Like (untested):
<snip>
> I believe that the only proper way to utilize a separate UID for
> a Web application is to start it separately from the HTTP server
> (say, with its own script run during the system's boot up), with
> the server communicating the application via a Unix socket.
>
> Then, either the starting script, a helper, or the Web
> application itself is responsible for dropping the root
> privileges. (Just as in the case of the HTTP server itself.)
>
> The use of Unix sockets allows for the Unix filesystem access
> control to be utilized, thus ensuring that the HTTP server
> passes the (potentially sensitive) information contained within
> the HTTP request to the designated application. (It is much
> harder to maintain this level of security with TCP/IP sockets.)
I agree with all of this.
> a Web application is to start it separately from the HTTP server
> (say, with its own script run during the system's boot up), with
> the server communicating the application via a Unix socket.
>
> Then, either the starting script, a helper, or the Web
> application itself is responsible for dropping the root
> privileges. (Just as in the case of the HTTP server itself.)
>
> The use of Unix sockets allows for the Unix filesystem access
> control to be utilized, thus ensuring that the HTTP server
> passes the (potentially sensitive) information contained within
> the HTTP request to the designated application. (It is much
> harder to maintain this level of security with TCP/IP sockets.)
> Unfortunately, AIUI, the mod_fcgid (as available for Apache 2.2)
> insists on starting the Fast CGI code by itself, thus requiring
> a set-UID wrapper to switch the UID.
>
> OTOH, mod_proxy_fcgi, while requiring for the Fast CGI code to
> be started separately, insists on using TCP/IP sockets.
has a FastCgiExternalServer directive for handling this. The module is
3rd-party, available from http://www.fastcgi.com (or, presumably, your
favourite distro).
Ben
Ivan Shmakov
Feb 22, 2013, 1:33:59 PM2/22/13
to
[...]
>> [Disregarded, and dropped news:comp.lang.perl.misc from
>> Followup-To:, as my questions below are little related to Perl.]
> [since I only read clpmisc I won't see any replies]
In a better Usenet, one'd simply "subscribe" to the thread
itself...
[...]
>> Unfortunately, AIUI, the mod_fcgid (as available for Apache 2.2)
>> insists on starting the Fast CGI code by itself, thus requiring a
>> set-UID wrapper to switch the UID.
>> OTOH, mod_proxy_fcgi, while requiring for the Fast CGI code to be
>> started separately, insists on using TCP/IP sockets.
> The (Perl) Catalyst documentation recommends mod_fastcgi (no 'd'),
> which has a FastCgiExternalServer directive for handling this.
Indeed, I was sure I've seen something like this while searching
the Web. Thanks!
> The module is 3rd-party, available from http://www.fastcgi.com (or,
> presumably, your favourite distro).
... Alas, it isn't free software (even if it is available free
of charge), which makes enough a difference for me.
I guess I'd have to patch mod_fastcgid instead.
>> [Disregarded, and dropped news:comp.lang.perl.misc from
>> Followup-To:, as my questions below are little related to Perl.]
> [since I only read clpmisc I won't see any replies]
itself...
[...]
>> Unfortunately, AIUI, the mod_fcgid (as available for Apache 2.2)
>> insists on starting the Fast CGI code by itself, thus requiring a
>> set-UID wrapper to switch the UID.
>> OTOH, mod_proxy_fcgi, while requiring for the Fast CGI code to be
>> started separately, insists on using TCP/IP sockets.
> The (Perl) Catalyst documentation recommends mod_fastcgi (no 'd'),
> which has a FastCgiExternalServer directive for handling this.
the Web. Thanks!
> The module is 3rd-party, available from http://www.fastcgi.com (or,
> presumably, your favourite distro).
of charge), which makes enough a difference for me.
I guess I'd have to patch mod_fastcgid instead.
0 new messages