Scripting is disabled for VHost [ApacheMain], access denied

[teledyn]

One of the many inconguencies encountered migrating from an Apache2 httpd.conf under RH(FC1) Linux :

Scripting is disabled for VHost [ApacheMain], access denied

I can't find anywhere in the server/vhost setup that lets me specify a 'scripting enable", or that lets me specify whether or not PHP is activated.

Before I'd enabled the ApacheMain on the Default listener, I had run the phpinfo() off the Example vhost, and it worked just fine. So PHP is there, and it works, it's just not there for this ApacheMain migrated config.

Other install inconguencies:

• Allow/Deny were left empty by the install, this apparently implies 'Deny ALL' as the ApacheMain vhost returned only 403 errors

• default logging places the vhost logs under /var/www/html??? that's like, publishing my access/error logs to the world???

• /opt/lsws/conf becomes owned by 'root', but the port-7080 admin listener runs as 'nobody' so all these conf files owned by root are not writable, and that means you set vhost settings over and over banging your head against it because it shows on the admin page as changed, but won't really change until you manually change these conf file and dir ownerships to 'nobody'

• now that the conf files are owned by 'nobody', any hacker PHP scripts that manage to slip by, eg if the PHP is inadvertently left with SAFE-MODE disabled, can read/write/delete your configuration. Shouldn't config files be owned by root?

• the default session timeout is way too short; by the time I've read a help page, it's timed out -- where is this set? Maybe the help pages could use a concept index?
  I eventually re-found this one, under the third admin realm -- which is logical since this only applies to the webmin interface, but it still shouldn't be set on a default as short as 5 minutes. It's also a good thing the install sets it, because the no-value default, according to the help pages, is a scant 1 minute!!

• somewhat related, what's with the 10-digit random (timestamp?) number on the admin realm? Totally frustrates using Firefox to remember and fill in the admin password and while I can see that as a feature for a site where the admin's desktop machine is an open-access terminal, I'm under Unix, nobody uses my machine (or my browser) unless they have my password, and if they have that, I'm screwed anyway. Since a bug is a feature that cannot be turned off, this seems like a bug.

 

[teledyn]

script enable does not propagate?

Found the PHP on-button ... under Server Config/Server/Script Handling there is a spot to set the PHP, and this was set, but the ApacheMain created by the migration scripts does not propagate this setting.

It's not obvious anywhere in the interface that "LiteSpeed API" means "PHP" -- you won't get to see the secondary option "phpLsapi" until after you select the LiteSpeed API, so looking at the vhost/Script Handling, there's nothing on that page or in the help page to tell you how to make PHP happen.

so the fix would seem to be ...

• go to the vhost Script Handling panel

• add the php extension and LiteSpeed API

• wait for the Handler Name select box to become populated with options

• select phpLsapi, then save

• go to Apply Changes and do a server restart

except that I did all that, and I still get the error

#ApacheMain] Scripting is disabled for VHost [ApacheMain], access denied.

:evil:

 

[mistwang]

Thank you for your suggestions, I will take a closer at them later.

To enabled scripting for a vhost, you need to set option http://www.litespeedtech.com/docs/VirtualHosts_Help.html#vhEnableScript,
It should be enabled by default, will check the migration script.

 

[mistwang]

You don't have to define a vhost level script handler when a server level script handler exists. It will take a little while to become familiar with all the configuration settings.

 

[teledyn]

It will take a little while to become familiar with all the configuration settings

Apparently :wink: -- but I'm hoping there's light at the end of the labyrinth!

Thanks for the tip to that ScriptEnable; I wonder if maybe there could be a configfile integrity check that says once you have enabled some scripting system, then Script Enable should also be checked. Even just a link to the other config form from the Script Handler prompt?

 

[mistwang]

We will change the default behavior to enable scripting when it is not set.

Answer to you other questions,

Allow/Deny were left empty by the install, this apparently implies 'Deny ALL' as the ApacheMain vhost returned only 403 errors

"Allow all' is the default, maybe it is because scripting is disabled?

default logging places the vhost logs under /var/www/html??? that's like, publishing my access/error logs to the world???

yes, that's a issue when relative path is given, should be fixed.

/opt/lsws/conf becomes owned by 'root', but the port-7080 admin listener runs as 'nobody' so all these conf files owned by root are not writable, and that means you set vhost settings over and over banging your head against it because it shows on the admin page as changed, but won't really change until you manually change these conf file and dir ownerships to 'nobody'

now that the conf files are owned by 'nobody', any hacker PHP scripts that manage to slip by, eg if the PHP is inadvertently left with SAFE-MODE disabled, can read/write/delete your configuration. Shouldn't config files be owned by root?

The configuration file must be writeable by the user that admin_php run as. You security concern is true, there is no other better solutions than running CGI script in SETUID mode under different user id(s).

In order to securely logoff your admin session with HTTP authentication, we add random number to the name of the admin realm. That's true that you can't let Firefox to remember the password. We may change to cookie based login to solve this issue.

 

[teledyn]

RH variant location for mysql.socket

one last config change, it seems the RedHat Apache2 and MySQL ship with a default socket location of /var/lib/mysql/mysql.sock, whereas lsws assumes /tmp/mysql.sock; the var/lib location needs to be added into the php.ini file, and there it is at long last, my intranet homepage.

And now for the really good news: This intranet uses Drupal.org, which rests its functioning on some really funky Apache rewrite rules, so twisted that the lhttpd was unable to emulate it in any fashion, but just like the docs say, the litespeed grokked the rules without skipping a beat!

 

[teledyn]

This one may be a show-stopper

I'll class this with the bugs that are features you can't turn off: LSWS does not permit running as the 'apache' user because that userid is less than the minimum value of 50

[ERROR] It is not allowed to run LiteSpeed web server on behalf of a privileged user/group, user id must not be less than 50 and group id must not be less than 10.UID of user 'apache' is 48, GID of group 'apache' is 48.

You can't even override by manually editing the XML.

This is bad news. Bad not only because I shouldn't be constrained from doing something potentially dangerous just so long as its not the default (like unSAFEMODE in php or the $SAFE in Ruby). Which RFC states webservers should not be run as uid 48? But it goes beyond just telling me how to run my business. It's mostly bad because although 'nobody' is considered the recommended alternative, because the 'apache' user is not permitted, LSWS is excluded as an apache replacement!

True, if one wanted to totally commit, you could use 'find' to hunt down every file and directory belonging to 'apache' and chown it to 'nobody' but for Linux systems with package managers, this becomes exceedingly frustrating as most applications (eg the nagios monitoring system) assume the 'apache' ownership on all sensitive files, and considering that you don't want to take the chances of some hacker being able to reboot your systems through seeding fake entries in the nagios alerts, non-nobody is a GoodThing.

So this LiteSpeed thing is certainly worth keeping my eye on, very interesting concept and fairly well executed, but looks like it will be a few releases for some multi-tier userid enhancements before I can make any real use of it.

 

[mistwang]

Which RFC states webservers should not be run as uid 48?

No, there is not. ;-) We did that for security reason, as user with lower id might be used by the system with a special privilege, so we want to make sure that those users cannot be used for web hosting by accidient. Maybe 50 is not a good chooice, we will lower it in next release to maybe 10.

That is true that LSWS did not ship with the most secure configuration as the default. The reason is, sometimes, it may breaks things in some environment and people will think LSWS is broken, it increases our time spending on unnecessary support as well.

But I can't agree with you that LSWS cannot be tuned to be as secure as Apache. ;-) LSWS is designed with security in mind, and you can do pretty much anything you can do with Apache to harden the security, and even more, like per vhost CGI chroot.

... but looks like it will be a few releases for some multi-tier userid enhancements before I can make any real use of it.

What does the 'some multi-tier userid enhancements' refer to? :?: I really want to know. We already have something like vhost level suEXEC CGI/FCGI/LSAPI implementation.

We do want to hear more feedbacks like yours to make our product even better. Thanks!