Re: SecurityException throwpoint audit

[Olli Vertanen <vertanen@cs.uku.fi>]

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@redhat.com>
> To: Tom Tromey <tromey@redhat.com>
> Cc: Anthony Green <green@redhat.com>
> 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
>