This is the mail archive of the
mailing list for the Mauve project.
Re: SecurityException throwpoint audit
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
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
You seem to check unexpected exceptions (I looked at
FileInputStream/security.java) but what about checking that
expected exceptions are thrown?
> Hi Olli,
> Yeah, I'm working on it, slowly but surely. Currently the
> only information online is the automatic status page at
> 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.
> ----- Forwarded message from Gary Benson -----
> Date: Mon, 15 May 2006 16:51:31 +0100
> From: Gary Benson <firstname.lastname@example.org>
> To: Tom Tromey <email@example.com>
> Cc: Anthony Green <firstname.lastname@example.org>
> 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
> 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...