The only true answer is: learn to add three lines of PHP code. http://paris2009.drupalcon.org/session/how-use-light-side-bend-drupal-your-w...
Sounds like a RemoveNode module waiting to happen. End users who don't code can get the benefit from those who do.
Would such a module be embargoed until after Gábor's talk? :) Going back to Robert's original point, it would be good to have a way of reliably stripping back fresh-install Drupal so that there are *no* surprises like this. He only highlights one URL but other URLs "leak" outside the q=admin namespace quite happily. Just writing a module to fight q=node doesn't protect you against q=rss.xml, for example. Admittedly both those examples are handled by node.module, so the issue Karoly mentions would certainly be one solution to that, but you shouldn't have to turn node.module off, or patch core, just to turn q=node off. What if I (as a non-PHP site developer) want nodes of content on my site (not unreasonably), but don't want q=node to respond with a potentially theme-garbled page (also not unreasonably)? Some sort of glob- or regex-based URL locking-down, and some sort of developer tool to investigate and poke the callback registry in real time (kitten.module, anyone?) without ploughing through var_dump() outputs, would both be great. I'd love the chance to get involved with rapid-prototyping this sort of thing at Drupalcon: hopefully the Light Side will live on after the actual talk, all hazy and indistinct like Alec Guinness. Cheers, J-P