[Catalyst] Cached TT w/mod_perl issue? Or just a Toby-bug?
Toby Corkindale
tjc at wintrmute.net
Wed Sep 28 12:34:17 CEST 2005
On Tue, Sep 27, 2005 at 01:18:10PM -0500, Wade.Stuart at fallon.com wrote:
> Welp,
>
> 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.
> 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 change uid) 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.
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?
> * 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.
> * 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?
yrs,
Toby
> Toby Corkindale
> <tjc at wintrmute.ne
> t> To
> Sent by: The elegant MVC web framework
> catalyst-bounces@ <catalyst at lists.rawmode.org>
> lists.rawmode.org cc
>
> Subject
> 09/27/05 08:40 AM Re: [Catalyst] Cached TT w/mod_perl
> issue? Or just a Toby-bug?
>
> Please respond to
> The elegant MVC
> web framework
> <catalyst at lists.r
> awmode.org>
>
>
>
>
>
>
> On Fri, Sep 23, 2005 at 05:07:58PM +0100, Matt S Trout wrote:
> > On Fri, Sep 23, 2005 at 03:46:17PM +0100, Toby Corkindale wrote:
> > > Hi, I just wondered if anyone had any thoughts on the below problem?
> > > It basically just comes down to this issue:
> > > 1) apache w/mod_perl starts up, running as root, and initialises some
> > > parts of the Catalyst system.
> > > 2) TT's cache directory is created as root, and a tree is created
> underneath
> > > it, also owned by root.
> > > 3) Apache setuid()s to the apache user
> > > 4) Catalyst can no-longer write to the TT cache directory, as it has
> > > insufficient permissions.
> > >
> > > I can work around this by doing a chown apache of the Catalyst cache
> dir
> > > during startup, but this seems poor form.. Plus requires to know what
> the
> > > apache user's name is in advance, which potentially varies between
> > > distributions.
> > >
> > > Is there a more sensible way to do this?
> > >
> > > Note that using $> doesn't work, as you have already set the TT cache
> dir in
> > > the config during the initialisation as root (euid=0), before the
> setuid
> > > occurs.
> >
> > Delay MyApp->setup until a PerlChildInitHandler?
>
> - Seems a bit tricky, and potentially unportable. If you have time, how
> would
> you suggest going about it?
>
> > Or have the TT cache dir set to a *group* apache can write to and setgid
> > so the permissions propagate so group write sorts the problem.
>
> Ideally, we'd like our app to be able ot start up and create the dir
> automatically; I had considered using the setgid trick to retain
> permissions,
> but past experience of setgid is that it always ends up getting lost
> somewhere, accidentally. (eg. Someone copies directories without realising
> they need to maintain it)
> Setting to a group that apache can write to relies on knowing and setting
> that
> group somewhere in a config file, and I'd prefer to try to and avoid
> system-dependant variables where possible.
>
> I'm surprised that no-one seems to have hit this; Do few people run
> mod_perl
> with a cache-enabled TT?
>
> tjc
More information about the Catalyst
mailing list