httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28116] - public_html (user redirect) is broken across cgi files
Date Mon, 05 Apr 2004 05:15:01 GMT
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

dkap+Apache@haven.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |



------- Additional Comments From dkap+Apache@haven.org  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message