public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Gary Benson <gbenson@redhat.com>
Cc: mauve-discuss@sources.redhat.com
Subject: Re: SecurityException throwpoint audit
Date: Fri, 25 Nov 2005 00:02:00 -0000	[thread overview]
Message-ID: <1132876894.5568.31.camel@localhost.localdomain> (raw)
In-Reply-To: <20051121165809.GB12340@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Hi Gary,

On Mon, 2005-11-21 at 16:58 +0000, Gary Benson wrote:
> I've been trying to work out how to test that permissions are checked
> at every point they ought to be.  There's a table of every such point
> here:
> 
>   http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods

I would not trust that list as the definite guide. I just looked for a
random method (which I was just working on for GNU Classpath)
Toolkit.getSystemSelection() and it was not listed.

> Some of these already have tests, but most probably do not.  Before I
> start creating tests I'm thinking that we need some way to correlate
> mauve tests with the throwpoints on this (and future) lists.
> 
> How would people feel if I numbered the throwpoints on the above list
> and noted them in their corresponding tests in some easily parsable
> form (probably in comments like Tags are already).  That way whether a
> throwpoint is tested (and the location of the test) can be found with
> a simple grep.
> 
> For simplicity I'd probably number the 1.4.2 list from 1-whatever.
> Checks added in 1.5 can be added at the end of the list.

I don't really like the numbering. I would propose to actually name the
tests with somewhat meaningful names. Something like
<PermissionClassName>_<ClassName>_<MethodName> for each Permission and
class.method() needing to check for that permission. (example:
AWTPermission_Toolkit_getSystemSelection)

Or maybe have a directory per PermissionClassName.

That is how jacks is setup. It follows the JLS, but it doesn't use the
section numbers, but logical names of the sections that the tests are
for.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2005-11-25  0:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21 16:58 Gary Benson
2005-11-22 16:27 ` Gary Benson
2005-11-25  0:02 ` Mark Wielaard [this message]
2005-11-25 19:30   ` Tom Tromey
2005-11-28 14:04   ` Gary Benson
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

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=1132876894.5568.31.camel@localhost.localdomain \
    --to=mark@klomp.org \
    --cc=gbenson@redhat.com \
    --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).