> Security wise any class could be loaded because Xindice is a secure product... right... We are not talking about a security flaw here, because there is absolutely no security at all in Xindice.
> Yes. But this is *really* dangerous too. Security wise any class could > be loaded, since what is done is just a Class.forName(), with no checks > at all. Find somehow your way to the server, put in the classpath > i.will.hack.you.UA430wn3d with a bad execute(HashMap map) method (or > don't really care about execute(), just use the default constructor to > mess up things), call it via the XML-RPC interface and you're in. A bit > too easy for my personal taste: there are too many Tomcats around > running as root. Let's paraphrase it: "find your way to the server, put in the classpath i.will.hack.you.UA430wn3d with a bad execute(HashMap map) method, modify the config-file, call it via the XML-RPC interface and you're in." I don't see how the config-file can protect you. Alternatively, you can put a new class "org.apache.xindice.server.rpc.message.Get", shutdown and reboot Tomcat and you don't even need to modify the config file. > The user in this case is a sysadm that is supposed to know what she's > doing. Xindice is AFAIK still used by regular users and not ready for Fortune 100 companies. > the first implementation might be rough, > but then we might easily switch to something more robust if the user has to change every config file with every new release, I don't call this an "easy switch". > Heck, we'll have to think about security sooner or later, don't we? :-) Totally agree. So let's think about it NOW. First implement an ACL-based system and then see how we can integrate this security in the XML-RPC calls. Not the other way around. -Vladimir ===== Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
