Gary, Thanks for your reply! So throwpoint checks are in these security.java testlets under various directories? Do you have a driver that could run just the security tests and nothing else? If not, what would be best strategy to implement one? I can try to write some tests, but your report list seems to be a bit broken right now. I'm interested in the security manager and the access controller. You seem to check unexpected exceptions (I looked at FileInputStream/security.java) but what about checking that expected exceptions are thrown? Olli > Hi Olli, > > Yeah, I'm working on it, slowly but surely. Currently the > only information online is the automatic status page at > http://people.redhat.com/gbenson/throwpoint-report.html. > I have some stuff I wrote the other day for Tom Tromey > and Anthony Green which I'm tidying up for the wiki but > I've attached it below in case you're interested. > > Cheers, > Gary > > ----- Forwarded message from Gary Benson ----- > Date: Mon, 15 May 2006 16:51:31 +0100 > From: Gary Benson <gbenson@xxxxxxxxxx> > To: Tom Tromey <tromey@xxxxxxxxxx> > Cc: Anthony Green <green@xxxxxxxxxx> > Subject: Re: question about security stuff... > > Hi Tom, Anthony, > > Most of the security work I've been doing is driven by writing > throwpoint tests for Mauve. There's a list of every throwpoint > at http://tinyurl.com/o2ttz and what I do is pick a class and > write a Mauve test for it. Sometimes it's easy, other times > whether or not a check happens is governed by some really bizarre > logic and getting it right is a fiddle. > > If you want to write throwpoint tests then that'd be really > helpful. There's a list of what's done and what's not at > http://tinyurl.com/egrve (updated nightly) so pick something > that's not done and have a go. Currently I'm looking at AWT: > that, java.net and java.security are the gaping holes at the > moment. > > Most of the dirty work happens in TestSecurityManager2. > First you call its prepareChecks() to tell it what permissions > you expect to be checked, then you call whatever should perform > the check, and finally you call its checkAllChecked() method. > Any unexpected checks will cause a SecurityException to be > thrown. As well as a list of must-check permissions you can > supply prepareChecks() with some permissions that may be checked > (there's some cases where Sun or IBM check something incidental > that Classpath does not) and there's also a different way of > running checks to allow stuff like System.exit() to be tested > without actually exiting the VM. > > gnu/testlet/java/io/FileInputStream/security.java is a nice > simple one to base things on. Some stuff requires different > classloaders or different threads and if you need that then > look at gnu/testlet/java/lang/Thread/security.java to see what > I mean. The "// throwpoint:" comments are for the nightly > status page. > > Of course, there's always PR libgcj/13603 if you don't fancy > throwpoint tests... > > Cheers, > Gary >
