There's a bug in my bug(zilla)



  • Today when I was on a phone-in meeting, the client I am doing work for was announcing that they are moving to the 21st century by implementing bugzilla for the staff. This being done by purchasing a hosted solution at bugopolis.com. As I was only on a voice connection I couldn't see the demo taking place, but I heard the presenter mention the URL .. so I went clickety click and entered client.bugopolis.com/dept into the nearest browser window, expecting to see at the very least the landing page for the department.

    Instead I go presented with the contents of the directory at client.bugopolis.com/dept and could navigate up and down the tree and look at the contents of various files. "Hmm that's not right" I thought to my self. As even though I can count on one hand the number of web-servers that I have set up I could see that something was all screwy. So I chimed into the meeting and sad "hey guys .. this isn't right". After describing what I could see, the reply was "It works for us, it must be that Safari browser you are using". So I jumped on IE and did the same thing and saw the same result. Other people in the meeting jumped on their smart phones and saw the correct page.

    Then someone asked .. "that was https://client.bugopolis.com/dept that you navigated to, wasn't it, and not just client.bugopolis.com/dept?". So the I tried https and lo and behold I was finally able to see the correct landing page.

    So someone (probably at bugopolis seeing that this is a hosted service) has screwed up the web-server configuration and not redirected http traffic to the https site. In addition, when I surf to just client.bugopolis.com I also see the default Apache webpage ("Apache 2 Test Page powered by CentOS"). Seeing this sort of thing scares me, as if someone has screwed up on the visible parts I start to ask questions about what they could have screwed up on the parts I can't see. And surely the hosting service should have just pressed a button to run a script to build a default site, and not done anything manually. Yes? Surely?



  • Bugzilla is the 21st century? Was there another 21st century like, I dunno, a decade before this one? Maybe you're referring to that 21st century.



  • @blakeyrat said:

    Bugzilla is the 21st century? Was there another 21st century like, I dunno, a decade before this one? Maybe you're referring to that 21st century.

    Hey, 2000.999999999899999987424 was in the 21st century!



  • @OzPeter said:

    Seeing this sort of thing scares me, as if someone has screwed up on the visible parts I start to ask questions about what they could have screwed up on the parts I can't see.
     

    +1. Seeing this sort of thing births that small acorn called "if they can't even get basics right, what hope for the more complex stuff?" in my mind.

    @OzPeter said:

    And surely the hosting service should have just pressed a button to run a script to build a default site, and not done anything manually. Yes? Surely?

    On ym server, creating a new vhost with an apache entry (including suPHP and mod_security) and dropping placeholder directories for webroot, logs, configs, php sessions and tmp areas into someone's home directory is a one-line script for me. 

    But then, I've done it so often I ended up scripting it for ease of deployment and consistency across all sites. I don't think hosting services would --- ohhhhhh.....



  • @Cassidy said:

    including suPHP and mod_security)

    Bugzilla is Perl-based. WTF do they need suPHP for?

     



  • @Mr. DOS said:

    @Cassidy said:

    including suPHP and mod_security)

    Bugzilla is Perl-based. WTF do they need suPHP for?

     

    suexec then?



  • @Zemm said:

    suexec then?

    Why suAnything in a world where mod_ruid2 exists?



  • @Mr. DOS said:

    Bugzilla is Perl-based. WTF do they need suPHP for?
     

    They probably don't. Was simply bragging that I'm not a hosting company and yet I have easier (and apparently more secure) deployment measures than they seem to have.

    @Mr. DOS said:

    Why suAnything in a world where mod_ruid2 exists?

    suPHP also provides each vhost with its own indivudal php.ini config settings. Not sure if ruid2 does that.

    However, that module looks interesting. There any further documentation other than "mod_ruid2 is a suexec module"...?

     



  • @Cassidy said:

    They probably don't. Was simply bragging that I'm not a hosting company and yet I have easier (and apparently more secure) deployment measures than they seem to have.

    Fair enough. Altogether too many “hosting companies” buy a WHM/cPanel license and let it do all the work for them without understanding what that work is.

    @Cassidy said:

    suPHP also provides each vhost with its own indivudal php.ini config settings. Not sure if ruid2 does that.

    Not so much. As opposed to specializing in running one thing (CGIs, mod_php, etc.) as a different user, it lets the entire Apache worker process assume the permissions of a user when serving the request, so everything relating to that request (SSIs, mod_*, CGI, etc.) runs as that user and with that user's permissions.

    @Cassidy said:

    However, that module looks interesting. There any further documentation other than "mod_ruid2 is a suexec module"...?

    How succinctly you have hit upon the project's greatest fault. The extent of its documentation is its readme; however, it's fairly intuitive to configure once you know what the available directives are.

    The big flaw I've noticed is that because ownership of worker processes is given to a non-www-user user, Apache gets really confused when it comes to counting up and maintaining the MinSpareThreads/MaxSpareThreads limits. YMMV. The other issue, which I'm not terribly concerned about but some might be, is that in order to change the ownership of worker processes, the master Apache process must run as root. Doesn't bother me too much as exploitation of that fact would require the presence of a fairly gaping hole very, very deep in Apache's guts, but it's something to be aware of.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.