DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28116>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28116 public_html (user redirect) is broken across cgi files [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2004-04-05 05:15 ------- 1) having worked in the software business (as in, the side that makes money) I know that UI (meaning user interface) bugs are real bugs, and it is a user interface problem I am documenting here. By saying that you just won't fix it, you are simply pissing people off. Not just me, simply do a Google search on the problem and see how many people are frustrated with it. By ignoring the suggested (and easy) fix, which is creating a FAQ entry, simply due to possibly some torturous grammer (though I did hand the bug entry to several of my friends, some of whom are techies, some of whom are writers, and one who is an english teacher) and none of them had trouble following what I was saying, or finding where my research lead, and how much of my time I put into fixing your bug, by documenting what was done by me. You don't easily document a) how to "turn off suexec" b) how to diagnose that it is suexec, as opposed to a Unix permissions problem, <Directory></Directory> permission problem, or any other problem, all of which it might actually be c) according to the logs, you never even bothered to check the examples I set up for you, just made assumptions d) when I did try the user support forums, they have many documented issues with various variations of the problem I'm having, but none with any actual solutions, nor any FAQs generated, the most I got was a "wo, ruff, man, bugzilla-it." e) actually read what I wrote about putting the information into a faq, which did involve I) how to not use suexec, if it was shipped to you II) why your error might all of a sudden show up because of suexec, after an upgrade or the like III) how to find out what your suexec actually is looking for, though, as I mentioned, that might be a security hole, due to now knowing where to put your compromising scripts. I did not ask for a FAQ on how to use the most precious suexec to actually protect files that all your warnings are about, or why one should only download and compile by hand every single binary that is used on the system, straight from the site that produced it, regardless of the amount of testing that would take, and the amount of hoops one has to jump through every single time, to compile it with all the flags, and recompile it with all the relevant latest modules, and cross-compiles, on each of the 370 or so machines that I support, running the piece of software, or, instead, depend on those saintly third-party distributors, who maintain a working compiled state of your software, combined with a working state of all the other little software bits necessary to produce other products. All I asked for was for you, who's product I have had the pleasure of using, up until this little problem, and, now that I've settled my issue, and was just hoping to help the other folks out there who didn't have the persistance, or, perhaps resources to follow it up to the extent that I did, or perhaps the advanced grasp of grammer that I manage to maintain, all I get is distain from you,Joshua Slive, whereas the consice and direct comments by André Malo, who didn't seem to have any problems divining my meanings, were actually helpful. 2) there might very well be a bug there, in suexec, for, with it running, I managed to get the (possibly potentially harmful) script running without being under it's perview, for if you bothered to actually read the bug reports I filed, expecially the first part, documenting the error that I was getting, you would see that none of the flags that suexec was compiled with were in operation in the Alias pointer, and therefore the script still should have failed under that circumstance ACCORDING TO YOUR OWN DOCUMETATION on suexec. THIS MIGHT BE A BUG. Give it to whatever QA folks you have to find out, for I have systems to run, and can't be your QA team, I have to keep "documented stable" configurations up and running. The above, was, of course, one of the reasons I ended up tracking suexec down last, through cryptic hints in various .h and make files, to find out if that was the failure, for, unlike your documentation, when it starts up, it doesn't say anything in the log files, and since, my log files (due to them being VirtualHosts (oh, and by the way, if you have something that is true within a context, and you make your docs searchable, you should maintain a consistancy with your tagging, and say VirtualHost every time, not an occasional one with a space between them)) are in a different location, the global suexec log file was not obviously in place (I did a grep across all the log files for the word "suexec" and it came up nowhere, had I not done a find on the / directory, looking for the binary, I never would have found the log file in the first place). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
