Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- CPAN vs. POD outside of .pm (.pl) files?
Re: [OT] non-issues with non-solutions
OTOH, I can't help thinking that it is a very strange coincidence that
Moose is positively unusable for CGI programs, provided that what is
reported about the time needed to compile it is correct (or - for that
matter - for anything which isn't 'a long-running application'[*]) and
that outspoken proponents of it want to make it more difficult for
people to write CGI programs by removing CGI.pm from the Perl
[*] Imagine that people actually write modularized and
object-oriented system configuration tools ...
> OTOH, I can't help thinking that it is a very strange coincidence
> that Moose is positively unusable for CGI programs, provided that
> what is reported about the time needed to compile it is correct (or -
> for that matter - for anything which isn't 'a long-running
> application' [*]) and that outspoken proponents of it want to make it
> more difficult for people to write CGI programs by removing CGI.pm
> from the Perl distribution.
CGI.pm appears to mix up CGI support and HTML generation, which
is a thing I see no good reason to do. So, I tend to advocate
in favor of replacing it with CGI::Simple whenever possible.
(My Web pages are generated with XML::LibXML::toFH (), anyway.)
Moreover, thanks to Fast CGI (and FCGI.pm), it's possible to
serve multiple HTTP requests without restarting the CGI code.
And, it may also allow for more flexible privilege separation
(than mod_suexec, anyway.)
As for Moose, I've scanned through the documentation, but didn't
quite grasp its utility as of yet.
> [*] Imagine that people actually write modularized and
> object-oriented system configuration tools ...
FSF associate member #7257
Re: a-Moose-ing CGI
The 'good reason' would be that CGI programs usually both consume
input and produce output. While I'm not particularly fond of the HTML
generation support in CGI.pm, the basic idea of generating HTML using
a procedural interface has something going for it: In this way, it
possible to use a 'high-level interface' whose parts represent the
logical structure of a form. This makes modifications of this logical
structure much easier than when having to deal with some kind of
proto-HTML markup language with an HTML-like syntax and some typically
fairy 'dumb' (insofar programmbility goes) support for value
interpolation. 'Circumstances' forced me to get some first-hand
experiences with JSF and RichFaces and the 'template pages' generated
in this way are generally huge, repetitive angle bracket swamps. I
understand that 'the typical programmer' never uses a loop (or -
heaven forbid - a subroutine) when he can just copy'n'paste identical
code fifteen times in a row (and thus minimize the amount of work
needed for each of the slightly different fifteen individual cases)
but the result of this is an unwieldy and rigid structure which
reminds me of a frozen rubbish heap (extended by throwing more stuff
onto it and waiting for it to freeze but never modified in any other
way as this would be prohibitively expensive).
I've had a look at that. A missing feature I absolutely need jumped at
me immediately: Support for accessing uploaded file data without
creating a temporary file first. Neither CGI.pm not CGI::Simple seem
to be 'maintained' in the sense that anybody bothers to deal with CPAN
bug reports, however, this here
is an absolute showstopper for me: I have to humour people with a
seriously high level of professional paranoia (yes, I do mean that) and
'open CVEs' are ratpoison in this respect. I can, of course, maintain
the code myself but I could as well just write it myself and the
result would very likely be less buggy and perform better for my use
... 'we can just write a long-running application instead' ... well,
yes. I've also done that in the past, although based on mod_perl (the
mod_perl I have even behaves like its documentation says it should
because I forced it to ...). But if I can get by with the more
'UNIX(*)-style' approach of using relatively small, independent
cooperating processes, I prefer to do that. Maybe because I'm old
enough that my first impression of this world wasn't the 'designed for
Windows 98' logo but young enough to feel no haste to chase whatever
happens to be modern now because it happens to be modern now (lest I
could be ... left behind !!1) but so be it.
Being able to switch UIDs on UNIX(*) means 'running with elevated
privileges' and if I don't absolutely have to use some 'huge' piece of
software for that whose innards are essentially unknown to me, I
prefer to avoid that. And this means small, setuid-0 C programs which
don't perform any function except 'uid switching', usually, to a
hard-coded persona, and only executable by the user supposed to execute
Re: a-Moose-ing CGI
I'm not sure what you're saying here. One of the major advantages of
FCGI/HTTP proxying rather than plain CGI is that it is straightforward
to have the webserver and the application itself running under separate
uids, both started (ultimately) from init, without having anything
setuid or running as root. This is impossible with CGI, since the
application is invoked by the webserver, so either it runs under the
webserver's uid or the webserver has to be able to switch uid.
I try to avoid setuid altogether. Daemons are started from /etc/rc or
managed with daemontools, and once that process tree has switched down
from root it never goes back.
Re: a-Moose-ing CGI
In the given context, that I wouldn't want to use mod_suexec for
anything as this would necessarily imply that 'the CGI executor' (or
at least some part of it) had to run with elevated privileges by
default and consequently, that mentioning it here is somewhat out of
One of disadvantages of separating 'a web application' into a 'web
server component' and 'an application server component' is that this
means that one more permanently running daemon must be configured to
run as an untrusted user and possibly even that it must be
specifically told that it shouldn't bind its network sockets to the
wildcard address (like JBoss) and possibly, it will even create
listening sockets bound to the wildcard address nevertheless (like
JBoss 5). Even if said application server doesn't kindly offer its own
'attack surface' (slight misuse of the term), it is still a bunch of
more code reachable from the network.
If 'the application is invoked from the webserver', this means it will
- by default - run as an unprivileged user with no additional
cost. This also includes that any access restrictions affecting this user
will - by default - affect the application as well (with no additional
[OT] CGI: "Fast" vs. "classic"
[Cross-posting to news:comp.infosystems.www.servers.unix.]
>> One of the major advantages of FCGI/HTTP proxying rather than plain
>> CGI is that it is straightforward to have the webserver and the
>> application itself running under separate uids, both started
>> (ultimately) from init, without having anything setuid or running as
> One of disadvantages of separating 'a web application' into a 'web
> server component' and 'an application server component' is that this
> means that one more permanently running daemon must be configured to
> run as an untrusted user and possibly even that it must be
> specifically told that it shouldn't bind its network sockets to the
> wildcard address (like JBoss)
It's certainly not impossible to fork a process which creates a
network socket bound to a wildcard address from a "classic" CGI
Not to mention that when properly implemented, the only socket
used by the "application server" would be a "Unix domain" one.
>> This is impossible with CGI, since the application is invoked by the
>> webserver, so either it runs under the webserver's uid or the
>> webserver has to be able to switch uid.
> If 'the application is invoked from the webserver', this means it
> will - by default - run as an unprivileged user with no additional
> cost. This also includes that any access restrictions affecting this
> user will - by default - affect the application as well (with no
> additional cost).
... However, if "a bunch of applications are invoked from the
Web server," this means that all of them will use the same
unprivileged user, thus ruining the privilege separation.
And why, even a single "classic" CGI application has enough
permissions to kill () its parent -- the HTTP server. Or to
mangle its logs, screw its runtime data (if any), etc.
Naturally, it's the very kind of problem which is easy to avoid
by having the "payload" process' lineage completely separated
from that of the HTTP server.
FSF associate member #7257
Re: [OT] CGI: "Fast" vs. "classic"
Unless this moves again into a different direction, I'm going to
ignore it. I'm interested in programming problems, here, programming
problems specifically relating to Perl, and not in this kind of "who's
the most fastly rotating humming top" 'system architecture theory
wars' (this is not supposed to be offensive, I just see no value in
such a discussion).
Re: a-Moose-ing CGI
I see. In that case, I entirely agree. I don't like the concept of
Well, I didn't say the application had to be written incompetently :).
Nevertheless, if you are obliged to run an app which is, it's much
easier to lock it down (with jails/MAC/whatever) if it's running as a
separately-managed process tree than if it's invoked ad-hoc by the
I don't want my applications running as the web server user. My apps
necessarily have access to files and other resources (database sockets
and so on) which I don't want to give the web server user access to. The
web server user is 'extremely untrusted', because it's running a process
which is directly exposed to the Internet; ideally, the system as a
whole would remain entirely secure even if the webserver process was
entirely compromised. (I don't suppose I reach that ideal in practice, I
do what I can in that direction.)
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum