Results 1 to 17 of 17
  1. #1
    Join Date
    Sep 2000
    Location
    Calcutta, India
    Posts
    144

    Unhappy

    Hi,

    I am hosting with catalog.com with a Red Hat server running Plesk as server administration software. I am finding a lot of problems in this reference and would appriciate any help from you guys.

    I am facing the problem in the CGI division. I am continiously getting "Prematures end of script headers problem" Also I am getting "File Open permission denied errors". I have shifted a lot of my customers from my previous hosting company which has gone out of business to this server and many scripts which were running on the previous server, after modification of path is not working on this server.

    I am having a feeling that this is due to the SuEXEC permission system, which was not there on the previous server. Can you guys advice me as how to go about solving this problem.

    I look forward to your help in desperation.

    Thanx for all your help.
    Submit2Please.com - Submit your site to 500+ SEO friendly directories
    EasySiteEdit.com - Point. Click. Edit. Works with existing site.

  2. #2
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    If you didn't have SuEXEC enabled on the previous server and do on the new one and that is creating your problems (and it definitely can if you try to just change it directly over), then you should be able to simply disable SuEXEC and that should solve the immediate problem.

    To do this, locate the "suexec" file, usually in /usr/local/apache/bin or /etc/httpd/bin or /usr/sbin or /sbin, etc. (type in "locate suexec" in a shell prompt to find it, if you have that option available). When you locate it, rename it to suexec_old or something. Then, check the web server for the User and Group directives and comment them out, so you don't get errors in that aspect, and then simply restart the web server.

    In worse case, you'll need to uncomment the User and Group directives, (which shouldn't be needed, unless you are using SuEXEC and have the files ownership and permissions set accordingly), and rename the suexec_old file back to it's original name and restart the web server.

    I'd suggest running the SuEXEC wrapper, rather than allowing people's scripts to all run as the same global user, but that doesn't require some initiative and changes, albeit fairly common, basic and simple. However, unless those changes are made (owner and group set properly, as well as permissions), then it certainly can pose a problem and give errors for certain users, depending on the permissions and ownership of files and/or directories... and what their script is doing.

  3. #3
    Join Date
    Sep 2000
    Location
    Calcutta, India
    Posts
    144

    Lightbulb Thanx Tim

    Thanx Tim,

    That was a useful piece of information. I hope I get it solved asap.

    However I would be greatful, if you can point me to some resources in reference to Suexec !

    Regards
    Abhishek
    Submit2Please.com - Submit your site to 500+ SEO friendly directories
    EasySiteEdit.com - Point. Click. Edit. Works with existing site.

  4. #4
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051

    Re: Thanx Tim

    Originally posted by talash
    Thanx Tim,

    That was a useful piece of information. I hope I get it solved asap.

    However I would be greatful, if you can point me to some resources in reference to Suexec !

    Regards
    Abhishek
    Nothing better than the Apache doc's, if you need any help after this, let me know. If I get some free time, I'mm offer my help and get your settled. In the meantime, here's a link:

    http://httpd.apache.org/docs/suexec.html

  5. #5
    Personally I've found the suexec documentation rather lacking. This is probably deliberate: They state at one point that "if you need documentation for this you don't know enough to be using setuid code".

    My prefered reference for suexec is suexec.c.

  6. #6
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Originally posted by cperciva
    Personally I've found the suexec documentation rather lacking. This is probably deliberate: They state at one point that "if you need documentation for this you don't know enough to be using setuid code".

    My prefered reference for suexec is suexec.c. ;)
    Ha, yes, this is true.. it can be rather daunting for people that aren't familiar. Certainly though, if people don't understand how to install it properly, they can make themselves a nice security hole. :-)

    I assume that basically anyone that hasn't installed SuEXEC before, or doesn't have step-by-step instructions, will need help, because that's just the way it goes with some of the Apache modules and whatnot. :-)

  7. #7
    Join Date
    Sep 2000
    Location
    Calcutta, India
    Posts
    144

    Lightbulb help would be appriciated

    Hi Tim,

    Thanx for your helpful reply. I have gone through the suexec documentation several times, but have not been able to figure out few things to get going on my server.

    Firstly, I think i need to take a backup of the httpds.conf file, so that whatever wrong happens, i can get back to the original status.

    Next, I want to ask that I am using Plesk, which in fact automatically updates these configuration files. Will that effect my changes ? How do i go about doing it in this case ?

    Also, even if we remove the suexec wrapper, a specified above, will the cgi programs start running or do i need to do something special to make them run ?

    Any help from your side will be highly appriciated.

    Regards
    Abhishek Rungta
    Submit2Please.com - Submit your site to 500+ SEO friendly directories
    EasySiteEdit.com - Point. Click. Edit. Works with existing site.

  8. #8
    If you remove the suexec wrapper -- or more specifically, if apache can't find it when it starts -- apache will not attempt to suexec cgi scripts but will instead run them with its own priviledges. Yes, cgi scripts will run, but they will be hopelessly insecure... by far the best option is to have a working (possibly heavily modified ) suexec installed.

  9. #9
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Originally posted by cperciva
    If you remove the suexec wrapper -- or more specifically, if apache can't find it when it starts -- apache will not attempt to suexec cgi scripts but will instead run them with its own priviledges. Yes, cgi scripts will run, but they will be hopelessly insecure... by far the best option is to have a working (possibly heavily modified ;) ) suexec installed.
    Agreed, but remember too, that more people than not, are more likely to write CGI scripts that will open up more of a security hole for their particular account, since any scripts running as their user have permission to delet or alter all files on their account, just as their user would. Of course, if people write poor code, that's their problem and it provides better protection, globally speaking and I would still enforce SuEXEC. If you still need help, email me and I'll see what I can do for you.

  10. #10
    Originally posted by Tim_Greer
    [lusers are idiots]
    Yes, but remember about natural selection. If you use suexec, the lusers who kill their accounts are the clueless ones who are costing you lots of support time... while if you don't use suexec, you immediately lose any clueful users you once had.

  11. #11
    Join Date
    Oct 2000
    Posts
    279

    Re: help would be appriciated

    Originally posted by talash
    Next, I want to ask that I am using Plesk, which in fact automatically updates these configuration files. Will that effect my changes ? How do i go about doing it in this case ?
    Unfortunately, I think you may be out of luck... Plesk updates the httpsd.conf file anytime you make a change in the site configurations through Plesk. While you can set the httpsd.stub.head and httpsd.stub.tail files, I think there's no way to fine-tune how virtual host settings are written.

    Getting the scripts to work with SuEXEC is probably less of a hassle.

  12. #12
    SUEXEC is no mystery people...

    SUEXEC governs CGI security and has very strict rules. To troubleshoot CGI problems it is best that:

    1) All the files must be owned by the user and group set in the VirtualHost in httpd.conf;

    2) All files and directories where CGI will be exec must not be world or group writable and must be at least user exec. Directories and Scripts should both set to 755 permissions;

    3) Data files that CGI scripts read and write must not be group or world writable;

    4) If number 1 through 3 are true and the scripts still do not work check the following logs:
    · /var/log/httpd/suexec_log (this will tell you if SUEXEC is failing the script)
    · /var/log/httpd/error_log (this will tell you what the script is failing on if the script passes SUEXEC checks);

    5) Add a "-w" to the first line of a perl script, i.e.,

    # !/usr/local/bin/perl -w

    This will add more verbose errors to the error_log;

    6) Check your code. Frequently there may be a line not closed with ";" or a routine that is not closed;

    7) Make sure that all modules and include files that are required by the scripts are located on the server and are in the proper locations.


    For more help with CGI troubles, see the following resources:

    Suexec Info:
    http://httpd.apache.org/docs/suexec.html

    Help with CGI:
    http://www.stars.com/Authoring/CGI/
    http://www.extropia.com/tutorials/misc/sherlock.html
    http://www.extropia.com/tutorials/we...ite_intro.html

    PERL resources Links:
    http://www.stars.com/Authoring/Langu.../Resources.htm

  13. #13
    Join Date
    Sep 2000
    Location
    Calcutta, India
    Posts
    144

    The real problem

    Originally posted by cperciva


    Yes, but remember about natural selection. If you use suexec, the lusers who kill their accounts are the clueless ones who are costing you lots of support time... while if you don't use suexec, you immediately lose any clueful users you once had.
    You know buddy, the real problem. Most of the customers, I have got are not expert with SuEXEC. They write poor codes most of the time and when the script does not run, they blame us for it. One of the customer has already left us for this .

    This is the reason I want to run without SuEXEC. After reading the post that Plesk is not flexible enough to make the apache run without Plesk, I feel really tensed. I am loosing the confidence to market my service though the speed is great and everything works fine.

    I have to find a solution.

    Abhishek
    Submit2Please.com - Submit your site to 500+ SEO friendly directories
    EasySiteEdit.com - Point. Click. Edit. Works with existing site.

  14. #14
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Originally posted by thewebbie
    SUEXEC is no mystery people...

    [SNIP]

    No, it's not a mystery. In fact, provided the user's have the correct permissions and everything else likely will be correct by default (i.e., ownership) upon uploading or creation, there's not really much to it -- and in reality, those scripts _should_ fail to execute. I personally believe SuEXEC should be enforced by default. However, we're talking not only about my opinions, etc., nor yours, but people that have users that SuEXEC gives the problems to, that you can explain in-depth about an they still won't get it.

    Still, I think those user's are going to be lost anyway at that poing. But, this person was asking about this, not for their sake, but for the sake that they probably don't know how to write a cron job to go and check and set the proper permissions every-so-often, automatically. This is what I did, to avoid user's having to ask questions about permissions that they didn't understand, it just fixes and sets it all for them automatically. The same can be done with the FTP server, to automatically set the proper permissions, etc. and still not just be guessing.

    However, this might not be a viable solution for everyone and their business -- even if they should make it one. Basically, SuEXEC is easy to set up, and as long as people set their files at the permissions they are supposed to be, they should have no problems with SuEXEC, well, not anymore problems than they would have without it anyway, which is another issue, since SuEXEC has everything set up for you and yes, the checking it does is a _good_ thing.

  15. #15
    Originally posted by Tim_Greer
    write a cron job to go and check and set the proper permissions every-so-often, automatically. This is what I did, to avoid user's having to ask questions about permissions that they didn't understand, it just fixes and sets it all for them automatically.
    You know, that would *really* scare me. If my files kept having their permissions changed, I would be convinced that someone had broken into the system and was messing with stuff; I would never even consider the possibility of a cron job which was doing that.

    Wouldn't it be polite to at least send an email to the relevant lusers telling them "one of your files was permitted wrong, we fixed it for you"?

  16. #16
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Originally posted by cperciva


    You know, that would *really* scare me. If my files kept having their permissions changed, I would be convinced that someone had broken into the system and was messing with stuff; I would never even consider the possibility of a cron job which was doing that.

    Wouldn't it be polite to at least send an email to the relevant lusers telling them "one of your files was permitted wrong, we fixed it for you"?
    Actually, the people were informed, yes. A cron to do these changes, is the best solution, I don't know why you would be against it. I informed the people that I would make these changes, as the former server they were moved from did not have SuEXEC and the new one did -- people having their cgi-bin directories at 777, etc. Basically, it only changed permissions on the files that were incorrect and wouldn't work anyway. It wouldn't just change them no matter what, unless they were too open.

    Another server this was implemented on, emailed the user it changed permissions for, telling them exactly what it did and why, and on what file -- which also explained how to properly set the permissions to better protect their files and conform with the web server. Nonetheless, when we first moved people from a server without the wrapper and suddenly had to it enforced, many people would have had problems. So, I ran this script initially without anyone knowing or caring and no one ever said anything. It depends if it's a change or something that's ran each night, etc.

    Certainly more than one change on a move or with notice informing people and why, then it's best to have it email people. No one should have a problem with that, I don't see why they would -- but yes, it's a good idea to notify them about said cron and what it does and why. They don't have to understand either, no one usually questions something that the web host emails them saying they are doing that will automatically better secure their user files. I don't know of an easier way.

  17. #17
    Join Date
    Sep 2000
    Location
    Calcutta, India
    Posts
    144

    where can i get such a script

    Thanx guys for all the info.
    Where can i get such a script to run as a cronjob and fix things for my clients ? Or do I need to write it on my own ?

    Regards
    Abhishek
    Submit2Please.com - Submit your site to 500+ SEO friendly directories
    EasySiteEdit.com - Point. Click. Edit. Works with existing site.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •