[Catalyst] Cached TT w/mod_perl issue? Or just a Toby-bug?

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Wed Sep 28 19:30:59 CEST 2005






> >
> >       You kinda sound like you want to have your cake and to eat it too
--
> > all while having someone else pay for dinner.  There is no magic bullet
> > that makes all the problems go away here.
>
> Uh, no. I'm seeing if someone else knows an elegant, thoughtful fix to
this
> issue, before I go off and re-invent the wheel. I'm not looking for a
magic
> bullet - I'm looking for discussion of the issue - Although that appears
to be
> something you don't seem to want to add to sensibly.

My point is you have made choices about your environment that is forcing
you into a more difficult corner.

>
> > All of these solutions require thought, have weaknesses, are inflexible
in
> > some way or another -- you are in this position by previous choices you
> > have made (starting apache as root and changing ID).   Sometimes it
does
> > seem silly to ask for directions after you decide to drive half way
across
> > the country,  you may not like that the answers all involve driving
> > backwards 15 hours.
>
> I see from your comments near the end of your email that you think that
my
> choice to use mod_perl, and to run apache as root (and let it changeuid)
is a
> great mistake. Since those methodologies are quite common on high-traffic
> dynamic public facing websites, I am genuinely interested to hear your
reasons
> for suggesting that they are a poor choice of platform. Please, do go on.
>

No,  I am saying that you have chosen to do so -- you deal with the
results.  I don't run apache as root.  I setup production servers to do so
all the time.  There are many ways to do this, reverse (caching) proxies,
port translation on firewalls, etc..
https://itso.iu.edu/You_Don't_Need_Root_for_That has a simple ipchains port
forward solution.  I suppose if you want to run
apache/mod_perl/mysql/gogo-gadget out of the box on linux distros and can't
be bothered to secure the systems, you can continue they way you are.


>
> As per your other responses:
>
> > *  You can make Apache start as the apache user and not change ID.
>
> Apache starts as root on almost every Linux distro; requiring that
sysadmins
> hack their servers to start as a certain user, just to run our app, is a
> suggestion that will not fly.
>
> > *  You can leave root -> userid apache and change your umask and make
the
> > dirs and files writable by all.
>
> Which really doesn't sound a particularly secure way to do things. So why
> compromise with it?

I would not, I was listing it because it is one of the options.  As you
seem to want "easy" options where "... considered using the setgid trick to
retain permissions,
but past experience of setgid is that it always ends up getting
lostsomewhere, accidentally. (eg. Someone copies directories without
realising they need to maintain it)" type of issues may be avoided.  Mind
you, that you may also mount filesystems read only to protect from those
pesky "rm -rf /" issues.

>
> > *  You can create the directories before hand and set permission to
work
> > like you need them to.
>
> Harder than it sounds, as the TT create also mkdirs a bunch of
subdirectories,
> dependant upon the template tree structure. Doing it automatically is a
much
> better idea than training the sysadmins to do it (and correctly) every
time
> they install a system, or the config changes.

It is not,  the sticky group bit message that I sent out before gets set on
all files and folders created inside that directory and forces the group to
be the same.  You only have to create the top TT cache dir and set sticky
bit on this.  But alas,  If you cant handle 4 command lines to do so (or
making a script to change that to 1 command line if you do it umpteen times
a day),  or if you think the people managing your servers and apps cant
handle a 4 command line or 1 script exec prereq I have no idea how you
expect them to setup apache/mod_perl/mysql not to mention the recursive
dependances nightmare that is the Catalyst install.  Hell, if you want them
created "on startup" modify your httpd startup script to do so.

You could also set COMPILE_EXT and not COMPILE_DIR and that would build the
template cache in the same dir as the real templates avoiding the whole
dynamic template dir all together -- but alas you would have to give up
even more security having writable template dirs.


>
> > *  You can hold off on the TT create until apache has changed ID.
>
> Preferable, and the lesser of evils - I even asked for advice on how to
go
> about that in a previous email to this list, although you seem to have
ignored
> that. Since you seem to think yourself superior in your knowledge of
perl,
> apache and catalyst, perhaps you would like to volunteer something useful
> yourself?

Sure,  dig into Catalyst core and setup a childinithandler for tt. and deal
with all of the complexities that creates for you.  The problem is of your
making, all of the fun cleaning it up should be yours as well.

use Apache::ServerUtil;

            Apache->server->push_handlers(PerlChildInitHandler =>
\&ttchildinit);




More information about the Catalyst mailing list