I need CGIwrap....

[chrispy]

I need CGIwrap to solve a chmod problem in an online store. Anyone know if HostRocket supports this? How do you install it? What would the path be to use it? Is it part of Perl and therefore already on the server? Do I only need to create a cgiwrap folder in my cgi-bin?

Any help is appreciated!
Chrispy

[don5408]

"I need CGIwrap to solve a chmod problem in an online store. Anyone know if HostRocket supports this? How do you install it? What would the path be to use it?"

Hi, Chrispy. Yes, HostRocket supports CGIwrap. To enable it on your account just go to "CGI scripts" in your HostRocket Control Panel and click on the "scgi-bin" link.

When you do this a scgi-bin folder will be created under your public_html folder automatically. Place any scripts which you wish to have run under your userid rather than 'user nobody' in the scgi-bin folder. Update the paths to the script(s) in the scgi-bin folder as necessary to /home/swiftly/public_html/scgi-bin

Hope that helps!
Don

[chrispy]

Do I need to chmod anything?

[don5408]

"Do I need to chmod anything?"

As far as the scgi-bin folder itself, no. You will however have to change the permissions (chmod) of any Perl scripts which you add to the scgi-bin folder to make the files executible just as you would when installing scripts in your regular cgi-bin folder (there's really no difference between the cgi-bin folder and the scgi-bin folder when it comes to file permissions, the purpose of using CGIwrap is to avoid issues due to file ownership).

I see that you mention that you are looking to use CGIwrap "to solve a chmod problem", if you need any further assistance it might help if you post back with some details on the problem you're trying to resolve.

Don

[chrispy]

I have a uShop store on one of my sites. I realized recently that it was totally unsecure. I have been back and forth with the creator of the software and have been unable to get the scripts to work right chmod'ing them as the software documentation instructs. Finally I was told to use cgiwrap so that I can the scripts can access the text files in the "data" and "data2" folders.

According to the original documentation the scripts must be chmoded 755 but the data folders must be 733. Even in the scgi-bin, the ushop.pl script cannot open the text files necessary.

This is the final documentation that they posted to me on the ushop support forum:

"Again as described on this security page:
http://www.uburst.com/uShop/security.html

It is important that your "data" directory is not visible to regular website visitors.

So, ideally, the permissions on that "data" directory should be 700 or 733. If you find that you must you chmod 777 in order to get data to write to that directory, then you should make sure that just going to the URL of the directory does not permit regular website visitors from accessing the files in the directory.

In fact, you should get some sort of "Permission Denied" message such as when you try to access the "data" directory on our server:

http://www.uburst.com/cgi-bin/ushop/data/

What the permission on the "data" directory can be set as.... and still allow CGI scripts to access it... depends on who CGI scripts are run as. By default, CGI Scripts often run as "nobody" or perhaps "www".... so the permissions would have to be such that those users can access the bin.

You should consult your web hosting provider on how to setup your directory such that CGI scripts have permission to read/write to your cgi-bin/data directory.... while regular website visitors cannot access your cgi-bin/data directory. They should be able to help.

If anything, they will probably provide a way to use "cgi-wrap" on their server. CGI WRAP will allow the script to run as a user that has permission to read/write to a chmod 700 directory. CGI WRAP will be setup differently on every server, but as an example, our CGI Test script can be accessed via the URL:

http://www.uburst.com/cgi-bin/cgitest.pl

However, on our server, CGI WRAP is setup such that you prepend "http://qs133.pair.com/cgi-bin/cgiwrap/uburst" onto the URL. So the same script can be accessed via the URL:

http://qs133.pair.com/cgi-bin/cgiwrap/uburst/cgitest.pl

(The above is slightly different for https)

Running the script through our cgi-wrap URL allows the script run as the user "uburst" and thus all it to access directories that are only accessible to the uburst user.

Again, you should consult with your web hosting provider on how to setup your directory such that CGI scripts have permission to read/write to your cgi-bin/data directory.... while regular website visitors cannot access your cgi-bin/data directory."

Your help is VERY MUCH appreciated!

-Chrispy

[chrispy]

PS! The path to my store is https://securehost26.hrwebservices.net/christianeducational.org/ushop/current/

Chrispy

Someone said it was a little different using SSL.

[don5408]

Hi. If you haven't already done so I'd urge you to submit a trouble ticket on this to get the input of HR's support staff. While I have a few general thoughts as to possible options as I'm hardly an expert in this area and you obviously want to make sure that your customer's data is as secure as possible I'd look to tap into the experience of HR's staff on this.

If a trouble ticket doesn't produce any results feel free to holler back...hopefully someone with more experience with setting up and securing online shopping carts than I will add their two cents, and if it comes down to it and you get *really, really* desperate (which in this particular case you would have to be ;-) I'll pick my brain and happily share the few fragments of on-topic lint I may be able to dig up.

Best of luck!
Don

[chrispy]

I have submitted a trouble ticket night before last. They have only replied with the most rudimentary suggestion. Did not read my documentation before replying. And now they are swamped and have not replied recently. I am going to call them this am. I still want to know anything you can suggest.

Thanks!
Chrispy

[don5408]

"I have submitted a trouble ticket night before last. They have only replied with the most rudimentary suggestion. Did not read my documentation before replying. And now they are swamped and have not replied recently. I am going to call them this am. I still want to know anything you can suggest."

Well hopefully you've been able to get with HR support and find a solution. Above and beyond my unfamiliarity with SSL under the circumstances this is a difficult problem in general to try to work through in a public forum...I wouldn't want to ask for any specific details which would require you to point out and effectively 'advertize' the location of potentially insecure data.

Just speaking generally my thinking is that if the issue here is that the data folders used by the script are currently browsable and accessable by the general public (and the script wont work with the folder's permissions set to anything other than 777) perhaps in leu of any better suggestions as an alternative you can add .htaccess (http://www.javascriptkit.com/howto/htaccess.shtml) files to these particular directories in order to restrict access (or at the very least to prevent the random browsing of their contents).

Best wishes,
Don