Hello,
On 1/26/2012 6:18 PM, Pete Helgren wrote:
If, as both you and Kevin said, these files should be accessible to
QTMHHTP1 because that is the profile CGIDEV2 will run under, then
changing the permissions to have *RX for QTMHHTP1 on those files and
removing permissions for QTMHHTTP should fix the permissions
(correct?).
Yes, you have the gist of it.
But, you should have *R authority (or higher) on the _files_, and *RX on
the _directories_.
That would also solve any problems with "stray" directives that I
might have (like the one you mentioned) because it seems that PHP and
Apache run under the QTMHHTTP user profile (at least it looks like
most of the files in my php apps have *RX permissions for QTMHHTTP
on them).
I agree with this technicality.
But, as you also said... leaving these directives in there will come
back to haunt you, so you should remove them.
If you leave them in, future developers will think they are required.
Possibly causing them to believe that similar directives are needed for
their own projects, spreading the "misinformation."
By coding it properly, you set a better example, and also perhaps cause
them to ask the question "why didn't Pete allow this? Hmmm... but his
application works great, so I guess they aren't needed." And that
spreads good information.
Furthermore, QTMHHTTP and QMTHHTP1 aren't set in stone, they are just
defaults. Someone down the line might change the user profiles things
run under. At one time, Zend had PHP running under userid=NOBODY.
Maybe next time, it'll be userid=ZENDUSER... Would it be obvious to
whomever is developing your system (which might be someone else down the
road) to go and change the authorities to block that userid as well?
And would you want them to do that, just because you left unnecessary
directives in the config?
That's just one scenario. Maybe you change the userids because your
users want to sign in and run with their own authorities... causes the
same problem as the scenario, above...
So I agree very strongly with removing them because it may come back to
haunt you :-) Plus, I really like code (whether it's configuration
code, or program source code) to "tell a story" -- it should be clear
what your configuration file is doing and not doing.
midrange.com
