Re: IFS File permissions

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.