Hey ppl....i have a big problem...my site is hosted with Liquid web...i never had problems with them but 3 days ago suddenly all the cgi files in my server (and i have a lot of them) started to create the usual files under "nobody" as owner...so i don't have the permissions to do anything with them....can be possible that it is a server admin issue, and that liquid web placed a cgi block on my site?

Please help me....:(:(:(:(

Thanks ;)

I think you should contact your host first.

To answer some of your questions, I don't think any paid host would block your cgi files unless the cgi files take large resources and CPU usage.

Have you contacted them already?

cheers,
:beer:

Nope....not yet...i think it is a server admin problem cause all the cgi inside my cgi-bin directory started to create files with 664 chmod and with nobody as owner....it is really strange that suddenly the UBB forum and all the others script become crazy all together...mmmm....:(

The thing that i would like to know is if it is possible that they block them in this way....

Hm... why don't you just call them and find it out?

cheers,
:beer:

Assuming doesn't help..
Contact them.

Originally posted by dektong
Hm... why don't you just call them and find it out?

cheers,
:beer:


Because I'm from Rome Guys ;);)

But i think the only thing to do is emailing them.....

As people are saying, contact them. If they were going to disable CGI for your site, there's better ways of doing it than that! In fact, that's no way to do it at all. It is likely that when Apache (or whatever web server they are using) was restarted, it couldn't find a file, such as suexec for the SuEXEC CGI wrapper to allow CGI scripts to run under your user, instead of the global user nobody. This likely is affecting more users than just your site, so they'll probably be glad to know. Also, be sure to check (if you use a control panel) that you didn't mistakenly disable the wrapper on your account.

Originally posted by klisis
Assuming doesn't help..
Contact them. Yeah, no offense Telemaco, but I really don't understand why people come here with posts like this before even trying to contact their hosts' tech support. Since you say you've never had any problem with LiquidWeb, I'd assume (since we're all assuming) that they might answer you, and maybe even fix the problem!

Originally posted by JayC
Originally posted by klisis
Assuming doesn't help..
Contact them. Yeah, no offense Telemaco, but I really don't understand why people come here with posts like this before even trying to contact their hosts' tech support. Since you say you've never had any problem with LiquidWeb, I'd assume (since we're all assuming) that they might answer you, and maybe even fix the problem!







Because before contacting them i wanted to know if it could be a problem related to my cgis instead their server.....only for this....

Thank you Guys for your help anyway :) :)

You did right to research first. It is better to know the possible answers before asking the question. Insight helps you read between the lines and to judge the plausibility of the reply. You were just charging your flack detector. Hi.
Let us know how it works out.
Gary

I guess really hosts should be glad that people do that kind of research before contacting support, but it seems you're adding an extra step to the process and so delaying resolution. But I can certainly understand wanting to know exactly what the possible problems are before you contact them; it helps get a complete and accurate answer from a tech support rep when you can ask a complete and accurate question!

Good luck...

Ok guys...this is the long answer (sarcasm) i got from Liquid Web:


"Looks like they all have permissions currently set to your domain. Please attempt to configure them again."


But my scripts still continue to create files with "nobody" as owner instead of me... :( :( :(

What should i do ?

I see this is a Unix server but is it Linux, FreeBSD or something else?

Are all of your CGIs in the same directory, if they are who has ownerhsip of that directory?

Finally, is the server running CGI-Wrap?

Originally posted by uuallan
I see this is a Unix server but is it Linux, FreeBSD or something else?

Are all of your CGIs in the same directory, if they are who has ownerhsip of that directory?

Finally, is the server running CGI-Wrap?


It uses Linux....no...i have different directories...the strange thing is that from now every cgi script that i put into my cgi-bin directory starts to create files with "nobody" as owner instead of "me" :( :(

If you place those same scripts outside of your cgi-bin directory does the same problem occur?

Also, do you know if you are using CGI-Wrap or not?

Is your cgi script creating files that are owned by nobody. If so, it looks like Apache is running as user nobody. The child cgi process inherits the uid of it's parent when it is forked. So if your cgi is forked from apache and then creates a file it is created as whatever user Apache runs as.

I tried to install a cgi outside the cgi-bin directory....it works, but the problem is the same....it creates files with "nobody" as owner instead of me... :( :(

And about the cgi-wrap...i dunno what it is and if it is installed on my server...

runs as nobody on all VDI servers so files created by the scripts belong to nobody. I also have a site where most all the pages are created by scripts so I've learned a few tricks to deal with them. First, If you copy the file to your local drive with FTP, delete the original file, reupload the file and chmod it properly it now belongs to you. I also have a script that works like a telnet window, because the script runs as nobody it allow you to work with the files that belong to nobody. Kinda a scarrrrrry script!!


Hope that helps....

Well, the permissions likely have no bearing on your problem. Permissions aren't what makes CGI scripts run as your user, it's a CGI wrapper, such as SuEXEC. However, it depends on what wrapper you're talking about. For example, if the permissions aren't set properly if Apache is running SuEXEC, the files will simply fail to execute and error. This is a _good thing_. If SuEXEC is enabled and it allows you to run scripts with the incorrect permissions, it's not set up properly and is likely insecure.

Personally, I don't see why anyone should run a web server and allow CGI without a wrapper. A CGI wrapper makes CGI scripts, files, directories, databases, etc. and their accesses more secure from other views, prevents user's from altering, deleting or creating new files or directories in another user's account directory. There's no reason to even give people the option of running CGI scripts as a web server's global user. It's a stupid idea and it adds risk in many aspects and makes it inherently less secure without a wrapper.

Nonetheless, without a CGI wrapper, scripts ought to fail without the proper permissions anyway. Any web server that allows CGI files to still execute with improper permissions, are not very knowledgeable. I've seen web servers allow people to run CGI scripts with permissions of 777, etc. Scripts should fail to execute if that is the permission setting. They ought to be at least 755 or the like. And, 700 is better. The only drawback to a CGI wrapper, is that some user's don't know how to set the permissions properly and follow poor install documentation that tells them to set their permissions to be world readable/writeable. Never a good idea, for obvious reasons.

My point is, the only reason why something like SuEXEC isn't a good idea sometimes, is because of the user's that set improper permissions on their files and SuEXEC refuses to run them. Again, that is a *good thing*, since scripts ought to fail anyway with such settings. The advantages, are more control over the user's processes, better security for the user's site's files and scripts, forcing proper settings on files and much more. If your web server is running Apache with SuEXEC and only runs the script as user "nobody" if the permissions aren't set properly, then the server is not set up properly and this sounds insecure and is. With a CGI wrapper, they should fail, and for good reason. The *only* reason why a user's script should run as a web server's global user, is if it's not set up properly. There should be no reasonable way to get around that, at all.

This specifically sounds like the scripts are running as the global user, because the web server was configured to run as such in your virtual host or global user dir directive setting. Note: Of course, some wrappers might just default to the global user, if the permissions are incorrect, but if that's the case, that is a poorly configured or poorly designed wrapper and I'd suggest them using SuEXEC, since if it's set up properly (which is *very* simple to do), it will ensure better performance and security for all the sites in question. There's no reason why a web server can't enforce user's to all run more secure sites, even without them knowing or caring. If a CGI script fails to run due to their lack of understanding of proper permissions, then they ought to do just that -- fail to run.

Finally, if that is the case, it's only a 30 second project to just write a cron job that checks the user's directory and file permissions and sets them properly for them without resulting in adverse effects on the server or the user's files or CGI scripts, etc. I'm surprised at your provider's response and I personally think it's pathetic, for the reasons I've outlined above.

You make some good points Tim, and I would agree that running a CGI Wrapper is the better alternative. Unfortunately, it also opens the door to a lot of Tech calls to the Hosting companies. Running scripts as "nobody" (aside from proper paths) means only having to deal with permission settings, which most people can handle — or learn very easily.

What caught my eye was your saying that scripts set as 777 should not be able to run scripts needing 755. Sounds conflicting to me. By definition, 777 includes 755 and "should" be able to run scripts. Being wide-open is less secure I'll admit, but I'm not familiar with an Apache setup that would not allow a setting of 777 to run. Would this also be a part of running CGI Wrap?

Setting aside permission settings, most people miss the boat with regard to script security. Also one of the main reasons why Free Scripts all say something to the effect that: "You use this script at your own risk." Using certain switches in the shebang or in the Sendmail path, are not familiar to most people, and some of the reasons why most Free scripts need to be closely examined for security holes.

For example, scripts like iKonboard and YABB both allow remote attackers to read local files, although these holes can be fixed. And I won't even go into the problems with Matt Wright scripts. I just advise people to never use them. ;)

hey Telemaco.
This is what you should do:
1. Click CGI-Wrapper script in your Cpanel.
2. upload you files to home/usr/public_html/scgi-bin.......... more instructions there.

But that doesn't always work. Plus that wrapper is crap.
Scripts that use php won't work under that wrapper since php on VDI server uses mod_php which runs in-process and can not have a different username.

I'll have to agree with Matt that the CPanel CGI wrapper is absolute crap, I spent 4 hours trying to get one script to run under it and still never got it working. Then again the same goes for Akopia Interchange under CPanel - I don't know a single person that has it working, yet it took me all of 30 minutes to get it stable on our old server at Alabanza.

Originally posted by Website Rob
You make some good points Tim, and I would agree that running a CGI Wrapper is the better alternative. Unfortunately, it also opens the door to a lot of Tech calls to the Hosting companies. Running scripts as "nobody" (aside from proper paths) means only having to deal with permission settings, which most people can handle — or learn very easily.

What caught my eye was your saying that scripts set as 777 should not be able to run scripts needing 755. Sounds conflicting to me. By definition, 777 includes 755 and "should" be able to run scripts. Being wide-open is less secure I'll admit, but I'm not familiar with an Apache setup that would not allow a setting of 777 to run. Would this also be a part of running CGI Wrap?

Setting aside permission settings, most people miss the boat with regard to script security. Also one of the main reasons why Free Scripts all say something to the effect that: "You use this script at your own risk." Using certain switches in the shebang or in the Sendmail path, are not familiar to most people, and some of the reasons why most Free scripts need to be closely examined for security holes.

For example, scripts like iKonboard and YABB both allow remote attackers to read local files, although these holes can be fixed. And I won't even go into the problems with Matt Wright scripts. I just advise people to never use them. ;)

Well, as I said, it can create errors that people normally wouldn't have result, but in actuality, those people weren't following the instructions well enough anyway. It can cause more support issues, but it can also help better prevent them too. You can just create a script that runs in a cron and sets all the proper permissions on their files and directories. That way, they don't get errors from not setting a writable file at world readable, writeable and executable. A lot of configurations will fail a script running at 777, actually, but obviously some do not. But, it's easy to get around any problems with the difference of permissions and it actually allows more freedom in your settings, or just as much. And yes, I know about and agree about the free scripts, ESPECIALLY Matt Wright scripts. I can't believe web hosts offer them by default as pre-installed. That's just mean!

OK, so how am are you supposed to get PHP scripts running as your user and not nobody on liquidweb? My scripts need to create directories, open files, write to them...etc, and I feel very queezy about having to have them set to 777 to get them working as nobody.

This is off the beaten subject, but I have to give Tim Greer a standing ovation. I have been reading his posts for a few weeks now, and this guy must have a keyboard surgically attached to his fingertips. Great responses, too. (albeit, a bit lengthy, on occasion.) I am very impressed with the broad range of topics he gets into. Over 400 posts, you guys! Give that guy an award.

Telamaco:

Could you please send me a message, via e-mail, ICQ or AIM? I would love to talk to you about Rome itself.

Thanks in advance.

Originally posted by ohbehave
OK, so how am are you supposed to get PHP scripts running as your user and not nobody on liquidweb? My scripts need to create directories, open files, write to them...etc, and I feel very queezy about having to have them set to 777 to get them working as nobody.

You can have your scripts create, read, write and delete files and directories easier with the SuEXEC CGI wrapper, since it doesn't require such wide open permissions to be set to work. This also does open up the risk of a poorly coded, insecure CGI script making it possible for someone to submit malicious values to the script, and if they are able to pass commands, they will run as your user and have the same permssions -- which would give someone the opportunity to wipe out all the files on your account.

However, poor, insecure code, is always a problem anyway. In addition, it's safer on a global level of the web server and al lthe user's accounts, whereas one user on the system can't write a CGI script to wipe out another user's files or databases, etc. For the wrapper to be set up, you'll need to contact your web host and have them implement it. It's very simply and fast to do, provided they know what they are doing. If you have any problems, let me know and I'll offer my assistance.

Originally posted by IPC PRO
This is off the beaten subject, but I have to give Tim Greer a standing ovation. I have been reading his posts for a few weeks now, and this guy must have a keyboard surgically attached to his fingertips. Great responses, too. (albeit, a bit lengthy, on occasion.) I am very impressed with the broad range of topics he gets into. Over 400 posts, you guys! Give that guy an award.

Hi, thanks for the positive comments, really. I can never have too many fans -- Just kidding. I hope that you find the information helpful, even if I do tend to really go into too much detail or type too much in the process, since that's what I'm here to do. Remember, I do take donations and gifts... Cars, houses, large bags of money (and no, not Monopoly money -- I'm not going to be tricked again, I tell you!! :-)

Cheers!

Liquidweb uses a special directory to run scripts as you. Go into your control panel, and then into the CGI Center section. Select the link Simple CGI Wrapper.

You'll see something like this:

Setup CGI wrapper for yourdomain

SCGI-Wrap is now enabled for yourdomain

You will need to put CGI's that you want to run with your userid in the directory

/home/yourlogin/public_html/scgi-bin

Once you do this they can be accessed at

http://yourdomain/scgi-bin/.

I've only been on Liquidweb for three weeks, but this is the way it's worked since I've been there. Any scripts in your general webspace - including cgi-bin - run as nobody.

-t :cool:

Thanks Tim, will contact LiquidWeb and ask them to install SuEXEC.

As for LiquidWeb, they were down for 6+ hours on Friday :(. I really hope it's VDI's problem and not theirs.

Originally posted by ohbehave
Thanks Tim, will contact LiquidWeb and ask them to install SuEXEC.

You shouldn't have to contact them for this, it's on your personal control panel. You should be able to do this yourself.


As for LiquidWeb, they were down for 6+ hours on Friday :(. I really hope it's VDI's problem and not theirs.

They said it was VDI, but I was able to use both the VDI and VO support forums all day without any problems - and I couldn't get my site to even come up. I'm not so sure it wasn't a problem at Liquidweb...

-Tim

Originally posted by IPC PRO
This is off the beaten subject, but I have to give Tim Greer a standing ovation. I have been reading his posts for a few weeks now, and this guy must have a keyboard surgically attached to his fingertips. Great responses, too. (albeit, a bit lengthy, on occasion.)

Rumor has it that he has an interface surgically implanted in his skull that allows direct thought to PC transmission, bypassing voice recognition, which he found too slow.

That would sure acoount for the lengthy posts.:D

thewitt:
The wrapper in the control panel is not an option for me, as quoted from MattF:
But that doesn't always work. Plus that wrapper is crap. Scripts that use php won't work under that wrapper since php on VDI server uses mod_php which runs in-process and can not have a different username.

Liquid Web replied to my e-mail about having SuEXEC installed, here it is, watch out it's almost 2 lines long:
"I am sorry but installing that is not an option available right now."

Great, there's no other way to have PHP scripts run as your user?

I missed that you were trying to run PHP scripts.

I wonder why this doesn't break perl scripts? I thought the mod_perl module module was installed as well, and my perl scripts definately run as me out of scgi-bin? Not that it helps your PHP scripts any.

So does this mean that on all VDI hosted servers, no one can run PHP code as any username other than nobody?

-t

I stand corrected. Mod_perl is not built into Apache on Liquidweb. That explains why perl scripts can change the owner and PHP scripts cannot.

-t