public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: mauve-discuss@sources.redhat.com, classpath@gnu.org
Subject: Re: SecurityException throwpoint audit
Date: Fri, 02 Jun 2006 11:55:00 -0000	[thread overview]
Message-ID: <20060602115528.GD3558@redhat.com> (raw)
In-Reply-To: <Pine.GSO.4.53.0605241534200.3494@cs.uku.fi>

Hi Olli,

Sorry for the slow response: I've not been too well this week.

There's no driver for running just the throwpoint checks, or just
the security-sensitive checks (though pretty much anything can be
security-sensitive).  The easiest way to do it would be I guess
to tag the relevant tests with a "throwpoint" or "security" tag
and use the existing tags mechanism to run them.  A tag for these
tests is long overdue actually.  Actually, most of the tests I've
written have no tags at all, which I think is wrong.  Perhaps
someone can enlighten me here.

Expected exceptions are checked: it all happens in the the calls to
sm.checkAllChecked().

And I fixed the report page -- the machine that generated them had
a disk crash a week or so ago, and something got locked up somewhere.

Cheers,
Gary

Olli Vertanen wrote:
> 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

  reply	other threads:[~2006-06-02 11:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 20:39 Olli Vertanen
2006-05-18 11:40 ` Gary Benson
2006-05-24 12:53   ` Olli Vertanen
2006-06-02 11:55     ` Gary Benson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-11-21 16:58 Gary Benson
2005-11-22 16:27 ` Gary Benson
2005-11-25  0:02 ` Mark Wielaard
2005-11-25 19:30   ` Tom Tromey
2005-11-28 14:04   ` Gary Benson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060602115528.GD3558@redhat.com \
    --to=gbenson@redhat.com \
    --cc=classpath@gnu.org \
    --cc=mauve-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).