I've read that the most competent hosts run suEXEC, but I'm not so sure about that. It appears too limiting to me for the user, and mostly beneficial to the host.

Also, why would a host that has suEXEC enabled, also offer cgi-wrap when they do the same thing... both use the users ID instead of nobody?

Why is letting your clients use scripts only under their user Id limiting?

You only need access to your scripts - Allowing permissions like 777 on cgi is asking for trouble - suexec is very necessary and still doesn't go far enough.. :D

If you use cgi-wrap instead of suEXEC, I think a 755 permission will work. Anyway, why both?

Cgi-wrap and suexec do the same job - I didn't read your post fully and didn't bear reference to cgi-wrap.

Just running scripts securely as possible is required :D

What about Suexec limits you? I hear people say what a pile of crap suexec is - Why? :D

With suEXEC enabled, I cannot change a permission from that file for a different file. The only way to get it to work is set everything at the dangerous 777 permission. Without suEXEC enabled, 755 works fine.

There do seem to be some rules that are a problem for some people - I haven't yet come across any - What does the script do?

It writes other files to another directory. Been reading up on suEXEC, and it seems to suggest putting things in a top directory, so maybe I'll try putting it above my www directory.

I still don't understand why my CPanel host would have cgi-wrap(scgi-bin) and suEXEC? I guess I should ask THEM.

suEXEC does limit where you can write data. I'm more of a fan of CGI-Wrap myself.

I don't see why CPanel servers have SuExec. With SuExec enabled, CGI scripts must be owned by the user that runs them. This prevents users from running any server-wide CGI script (even the ones that come with CPanel). Maybe I'm just missing something in the configuration, but I have had to disable SuExec on all of our CPanel servers, and just recommend using the CGI wrapper if a CGI script must be ran by the user.

Grrr... my host said that suEXEC is installed server-wide, and they will not change it. Their reason for having BOTH cgi-wrap & suEXEC was that "simple cgi-wrapper" just came with C Panel.

I could ask them to move me to another server of theirs that may not have it; but they may not have one or may not do it.

I'll try to redo my scripts and see if I can get them to work; but I'm doubtful.

To me, it's just silly to have a 600 or 700 permission, and because of suEXEC, it's world-readable. It should only be user-read/write for a 600 permission, and user-read/write/execute for a 700 permission.

suEXEC seems to take away the very thing that chmod permissions were meant for, and I don't like that. I think the user should be able to set their own permissions and umasks. And for perl, let us use tainting for security, etc; but don't limit ALL your users with ONE solution fits all, and to me that's exactly what suEXEC does. That's why I view the use of suEXEC as more for the host than for the customer; even though my host says it is for customer security. <rant over>

If I am wrong, please someone show me.

Chris, what's up with you and suexec lately? :)

http://www.webhostingtalk.com/showthread.php?threadid=66531

BTW: Tell your host that is using suexec AND CGI wrappers that I said they're idiots.

I'm dislexic, and I think I had this backwards. It seems that suEXEC "is" what I need. All my scripts run fine, so far. I could've just used cgi-wrap though.

I still don't care for the fact that a 700 or 600 file is world-readable; but I can always chmod those few files to 0, password protect them, or put them above my home directory.

Our suEXEC has been massaged quite a bit over time as we have fine tuned it for our client's needs.... however the docs are still the best source of reference in this area:

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

Limiting? Not at all. Smart? Very.

Originally posted by Deb
Our suEXEC has been massaged quite a bit over time as we have fine tuned it for our client's needs.... however the docs are still the best source of reference in this area:

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

Limiting? Not at all. Smart? Very.

Just read that page at the URL above last night. Well, if you, Deb, think suEXEC is smart, then I guess it's a good thing.

how do you handle suexec and ssl secure server? If an account does not have their own secure cert., they will not have their own virtualhost entry in the secure server, so suexec will not work. If you use cgiwrap, this can bypass .htaccess protection, which is not good either...

- John C.

Originally posted by JohnCrowley
how do you handle suexec and ssl secure server? If an account does not have their own secure cert., they will not have their own virtualhost entry in the secure server, so suexec will not work. If you use cgiwrap, this can bypass .htaccess protection, which is not good either...

- John C. It is true that it can be complicated, depending on your skill set and your requirements but it can be done. I know it can be done because we do have suEXEC working for sites with shard SSL certs, privately owned SSL certs, and of course with those that don't have SSL at all.

I wouldn't be able to explain 'how to make it work' as that would take some time that I don't have as well as a conference with the techs over here rather than myself, and a lot depends on your own setup...but I did want to note that if you put a little time into it you can accomplish the task.

Thanks Deb for the reply. We have fooled with a few ideas, but it can be a problem with people who use ecommerce cgi scripts that also use SSL and need to write to a file, as ownership problems come into play.

Other than that, suexec is great option.

- John C.

Originally posted by JohnCrowley
Thanks Deb for the reply. We have fooled with a few ideas, but it can be a problem with people who use ecommerce cgi scripts that also use SSL and need to write to a file, as ownership problems come into play.

Other than that, suexec is great option.

- John C. Just to be clear, it shouldn't be a problem at all as long as it's setup to handle it correctly. We have not experienced any complaints in the area and it is handling quite a few cgi scripts within the SSL realm etc etc... Tricky but doable. Just look at it inside out and upside down, you'll get it.

If you're anything like us you'll wake up in a cold sweat during a time you need sleep most and scream OHHHH!!!! LIGHT BULB!!! :D

Originally posted by JohnCrowley
how do you handle suexec and ssl secure server? If an account does not have their own secure cert., they will not have their own virtualhost entry in the secure server, so suexec will not work. If you use cgiwrap, this can bypass .htaccess protection, which is not good either...

We actually have the SSL and non-SSL sites all on the same shared apache server. Each SSL site has two virtual host entries. One for SSL and one for non-SSL. Suexec is used in both. This is for users that have their own cert.

I imagine that you could also split it up between two apache servers if you needed.

Our shared SSL stuff isn't part of the apache configuration. It's more of an offloading of an SSL area, similar to a third party SSL credit card gateway. We've never felt just in "sharing" our signed certificates in any other fashion, as they are supposed to show some type of identity.

Originally posted by chrisb
I've read that the most competent hosts run suEXEC, but I'm not so sure about that. It appears too limiting to me for the user, and mostly beneficial to the host.

Also, why would a host that has suEXEC enabled, also offer cgi-wrap when they do the same thing... both use the users ID instead of nobody?

There is absolutely nothing limiting about SuEXEC. It protects you and the system, there's no reason not to use it. Out of date and badly written documentation about how to run or set up a CGI script, lack of knowledge of permissions and ownership are the only reason why anyone might have a problem. If you learn about these things, SuEXEC is preferable (unless you have a really insecure script, but that's not SuEXEC's fault).

Originally posted by chrisb
With suEXEC enabled, I cannot change a permission from that file for a different file. The only way to get it to work is set everything at the dangerous 777 permission. Without suEXEC enabled, 755 works fine.

This doesn't make sense, there's something wrong with the way you're doing this or what you're trying to do. With SuEXEC is makes it so you DON'T have to use settings for world readable, writable and executable.

Originally posted by Deb
It is true that it can be complicated, depending on your skill set and your requirements but it can be done. I know it can be done because we do have suEXEC working for sites with shard SSL certs, privately owned SSL certs, and of course with those that don't have SSL at all.

I wouldn't be able to explain 'how to make it work' as that would take some time that I don't have as well as a conference with the techs over here rather than myself, and a lot depends on your own setup...but I did want to note that if you put a little time into it you can accomplish the task.

SuEXEC will work the same for user's without an individual Virtual host for each of them. It still works from their document root, it shouldn't matter or give anyone any problems be it a shared domain or sub domain, an IP or a virtual host, as anything in their /path/to/home directory will ensure the file is executed by them or it will fail. Global set ups will cause the problem, and that's not what SuEXEC is meant for anyway (I'm sure you know this, I'm explaining this for the other users' questions at the same time in response).

.

<Olive branch>

.

Threads are so much shorter this way.

>()))):>

.

Neat-o fish design ;)

>>-)))))))))))))))*>

heh, I was never much for text art. Now we all see why.

I'm still listening and learning. As I later changed my mind in this thread, and said that suEXEC seems to be EXACTLY what I needed, and all my scripts work fine.

Once I remembered, but then I forgot. (Oh how I wish you could remove your own posts).

I'm a freak, a super freak. Oh, super freaky!

chrisb> I am glad to hear you got them running. :) :) I know who to ask for Perl help, hee hee :D


:D Bailey

.

Seriously, I just try to be a happy person who uses a lot of smileys and is personable in her dealings with other users.


:D Bailey

chrisb> my apologies are to you. My purpose for posting in this thread was in response to a comment made by someone on page 1, all I wanted to do was assure that user that cPanel retains its functionality even with suEXEC enabled. I was once with a host whose scripts were literally not working (as in, error screens when I tried to use them) and I wanted to assure this user that the scripts do still function.

It's a good thread, and I'm glad you'd asked about suEXEC because I too wasn't entirely excited about it when I started using it.

:cool:


:D Bailey

Thanks Bailey, but you don't owe me any apology. I started the thread but that doesn't mean I own it.
Anyway, I expect people that work on the admin side of things OR people that have root access to know more about suEXEC than I do. I just don't know which of all of these wrappers are the best... SUSE, CGI-Wrap, etc. OR how they differ.

.

Starting to think you're makin' stuff up. :D

chrisb> well I know that cPanel comes with that cgi wrapper... and honestly as a user I never had the desire/need to invoke it. (Didn't understand it at that point, either) Now on the admin side of things, I see that people never use it on a box that has suEXEC disabled. Hence, what is the point? Perhaps it has usability on the user side, but for someone trying to monitor the server, not much.

I much prefer, administratively, knowing who's running what, than having everything run as a nobody process. As well, there are some scripts that kick their heels up with problems when "nobody" is a user... if you might have an occasion to search at the VO forums, you'll find some references about this in regards to a couple different scripts. I don't believe these are entirely addressed by suEXEC, but I might be wrong on that. Anyways suEXEC at least helps processes get assigned to users, but some of them can definitely be a trick.

;) Bailey

_____________ Fill in the blank.

I lost yours waaaaaaaay back. ;) If you find mine along the way, please let me know, okay?

:D Bailey

...and if we could please keep this going, I am only 2 more posts away from 300. So post something witty, will ya?

:D Bailey

You lost my mind, I'll loose yours!

:cool:

POST 300!!!!!!!!!!!!!!! Woooo-hooooo! And I believe we have just made at least a full page of nonsense. Fine, fine work. :D

Expert work done by professionals. :D By the way, is the olive-parmesan salad as good there as it is here? ;) Thanks.

*goes looking for pills

Dang it, all this excitement, and I forget.... :D

Originally posted by baileysemt123
chrisb> well I know that cPanel comes with that cgi wrapper... and honestly as a user I never had the desire/need to invoke it.

As well, there are some scripts that kick their heels up with problems when "nobody" is a user... if you might have an occasion to search at the VO forums, you'll find some references about this in regards to a couple different scripts. I don't believe these are entirely addressed by suEXEC, but I might be wrong on that. Anyways suEXEC at least helps processes get assigned to users, but some of them can definitely be a trick.

;) Bailey


Agoria.cgi that ships with cpanel often stops working and gives strange problems without CGI Wrapper. If you search the Yahoo mailing list archives on Agoria you will see many post about this porblem, in fact I think the lastest Docs for Agoria say you should install cgi wrap.

Originally posted by Monte



Agoria.cgi that ships with cpanel often stops working and gives strange problems without CGI Wrapper. If you search the Yahoo mailing list archives on Agoria you will see many post about this porblem, in fact I think the lastest Docs for Agoria say you should install cgi wrap.

Do you need to run agora shopping cart with cgi-wrap if Apache is already running suEXEC?

I honestly do not know that for sure Chris. I do not use the cart, all I know was I susbscribed to the support mail list for along time to learn more about the cart and I know it was an issue that Agoria had to have cgi wrap installed for the manager module to work properly.

Nothing would surprise me on that cart tho since it is a hack of a hack of a hack. Started as a hack of Selna Sol's web store and has been added to, hacked around on, and put together by every TDH that can write a line of perl code.