Same CGI, but one doesn't run!!

[Javier Mosqueda]

I have a perl script running perfectly, but I uploaded same file without different name and for some reason attributes are not the same - I've never touched the CuteFTP command "Change Attributes". First script has attributes 755 as the directory has (Owner's RWX, Group's R-X, Public's R-X), but now anything I upload put's Group's RWX and doesn't let the script to run.

Now I used the Change Attributes command of CuteFTP to have all at CHMOD 755 (rwxr-xr-x) and all scripts there:

randtxt.pl
rt13.pl (same as above)
rt131.pl (new version)

run well, but why is that first upload to my CGI-BIN directory inherited the attributes of the directory CORRECTLY, and recent uploads are adding a write attribute not available in the directory?

------------------
Javier Mosqueda
crystalking.com (http://crystalking.com)


[This message has been edited by Javier Mosqueda (edited 01-09-99).]

[Deb]

I just looked at all three of them and all three seem to be working....

Have you fixed them since you posted?

Deb

[Javier Mosqueda]

Yes, I CHMOD'em manually just now, and it gave me a lesson on file permissions.

Even now, I don't understand why just a group's write attribute doesn't let the script run.

I'm uploading a fourth file just copied from my computer into the CGI without touching the CHMOD.

NOW I'M NOT MOVING THE PERMISSIONS, THEY ARE THE ONES OBTAINED AUTOMATICALLY.

FILE IS:

RT13.CGI, loaded at 17:01 PM EST of today.

it's a plain copy of the RT13.PL

SEE? it took an extra write group's attribute.

WHY?

Thanks Deb.

------------------
Javier Mosqueda
crystalking.com (http://crystalking.com)

[Terra]

The Apache suEXEC CGI wrapper does not allow a script to be either 'world or group' writable...

There can be multiple people that belong to one group, and Apache doesn't know if the 'owner' of the file, authorized one of his group members to make a change...

Also, concept is *path of least resistance*... It is far easier to hack your way into a users group, then it is to become or hack the user themself...

Many hosting companies have horror stories of where they did not run tight security on their scripts, and malicious users would damage other peoples domains...

FutureQuest employs a *very* strict CGI policy, one for which we will not change...

We have already terminated 3 domains, because they were hackers that signed up for an account, then later found to have been focused on causing malicious damage to both the system and also to other domains... If I did not have our security protocols in place, then you domain could have been wiped out, without ryhme or reason...

--
Andrew Gillespie
Systems Administrator
FutureQuest.net

[meikel]

We have already terminated 3 domains, because they were hackers that signed up for an account

I hope the credit card information was ok http://www.aota.net/ubb/smile.gif The minimum to do to these hackers is to charge them the money.

Greetings from someone who hates people hacking my domain
[nbsp][nbsp]Meikel Weber
http://www.meikel.com

[pqwabbit]

hmm it would liek really kick butt if ya like had this program that nbot only detected hackes but like did something really mean back to em as soon as they was detected muahahhahahaha - kinda like that mail harvester thingy you got going there.

I read your policy on spammers but what about hackers? Same thing? No refund?
gee that would sure stink for them hehehee



------------------
Lea
Massachusetts Rabbit Rescue
www.RabbitRescue.org (http://www.RabbitRescue.org)
LJ Massey & Co.
http://www.massey.i-p-d.com/index.shtml

[Javier Mosqueda]

Thanks to everybody for your participation, I just wanted to leave some conclussions after some e-mail chat with FQuest.

1.- The FTP software is the responsible of uploading files with certain attributes or permissions, which not always are the ones required for the server to process those files. In the case of CGI's, they must be 755 (world and group read & execute but not write) and if the FTP program uploads the wrong setting one must force them to be the ones required by the server.

2.- I learned "hackers" and I thank the company for the protections to look after our domains.

3.- The CGI that I thought didn't work, now it works with just a simple 775-to-755 change in the file's attributes. It shows random messages (I removed the bad jokes) in case you are looking for a little thing like that.

Regards

------------------
Javier Mosqueda
crystalking.com (http://crystalking.com)


[This message has been edited by Javier Mosqueda (edited 01-10-99).]

[Deb]

Hey Javier...

Also per our conversations via email, Andrew has made some changes at the system to level to force 755 to the scripts and 644 to regular files.... You'll find this info in the Server News Forums. It should help out with situations like yours http://www.aota.net/ubb/smile.gif

Deb

[Javier Mosqueda]

Thanks http://www.aota.net/ubb/smile.gif http://www.aota.net/ubb/smile.gif http://www.aota.net/ubb/smile.gif

By the way, I forgot to write a fourth conclussion above:

4.- When uploading the CGI written in a text like Perl, the upload has to be done in ASCII mode. I run Windows and I noticed that when uploading in ASCII mode to the server the length of the file in the server is smaller than the length of the file in my computer (I don't know which control characters are removed perhaps CRLF are chopped to just CR?). The binary upload preserves all characters (CRLF) and the server doesn't like that, reporting an error when attempting to run the script.
------------------
Javier Mosqueda
crystalking.com (http://crystalking.com)


[This message has been edited by Javier Mosqueda (edited 01-11-99).]