There is a lot of confusion with the treatment of meta-data, and data in the policy file. There is no distinction between the two catagories. The definiton of meta-data and strings can easily be confused by the user, intentially (a hacker), or by mistake.

The policy file should have a very clear syntax /symantics, since users will configure their security policy with these files. An unintentional mistake done by a naiive user may break his security. Being consistent is very important in defining the policy file, so users can easily follow the rules.

The following statement in the policy file means that the file named * (star) has write permission:

permission java.io.FilePermission "*", "write";

Comparing it to other wildcards I would assume it meant all files in the current directory have write permission. I would doubt that the user meant the file * when writing this statement.
(currently for * to be a wildcard, it must be proceeded by a "/" (on solaris)).

Contrary to this:
permission java.io.FilePermission "-", "write";
This statement means that all files (from the root down) recursively have write permissions. This statement assumes absolute path, and is never treated as relative.
Currently there is no way to state that a file named '-' (and not all files recursively) has write permissions. "./-" means all the files from the cwd and down. One may question the use of "-" as a file name.


The problems occur becuase there is no distiction between meta-data and data. Here are a few examples of problems:
For example, currently people can't create a real file called "*" or "-"
unless they are granted the corresponding wildcard permission. For example:

new FileInputStream("/home/schemers/-")

will fail, even if I have "/home/schemers/*" permission. That is because
the checkPermission that is done will be done with a FilePermission
that thinks "/home/schemers/-" is a recursive-wildcard. I really think
the SecurityManager methods that construct FilePermission objects should
call a special version of the constructor that doesn't interpret wildcards.

The same goes for SocketPermission. People (i.e., hackers) might do
strange things with hostnames. The SocketPermissions created by
the SecurityManager shouldn't have wildcards expanded, and the port
should be passed into the constructor, not as part of the hostname.

For example, if someone trys to open a connection to port 5000, and the
hostname they give is "foo.bar.com:4000-", then it will actually cause
a checkPermission on "foo.bar.com:4000-5000". This doesn't seem like
a security hole, but it does seem troublesome.
 
The following paragrahs explain the reasoning behind the current implementation:
> Can I assume that '*' is wildcard in a policy file ?

nope. It is up to each permission to interpret what "*" means.

> -------------------------------------------------------------------
> and this one fails : an access control exception is raised:
>
> grant {
> permission java.io.FilePermission "*", "write";
>
> };
>

For FilePermission, the match-everything-in-the-world wildcard is
actually "-". We decided against "*" because "/dir/*" means every file
in a directory, while "/dir/-" means every file in a directory and
any subdirectory, so "-" seems to be a better choice if you
really want to match every single file. Note that we could couldn't
use "/-" (or "\\-" on win32) because although it works fine on
UNIX, on win32 "\\-" would only match all the files on the current
drive.

So you have:

"/dir/*" -> every file in "/dir"
"/dir/-" -> every file in /dir" and any sub-directories
"-" -> evrey file

In general I'm really not too fond of this syntax, and would like
a more general scheme (i.e., /dir/*.text is not allowed) that used
a real wildcard/regular-expression system, but that would obviously add
to the complexity and possibly create bugs.

>
> Roland,
>
> You wrote:
>
> > "/dir/*" -> every file in "/dir"
>
> so
> > permission java.io.FilePermission "*", "write";
>
> Does the '*' mean all files in the current directory ?????

Actually, I think it currently means the file called "*" in the current
directory. The reason being the FilePermission object looks for a file
that ends with File.seprator + "*" (before the file is canonicalized).
Thus a single "*" does not match "/*" (UNIX) or \* (win32). This can be
a bug or a feature depending on your viewpoint.

I've been tempted to ignore (and/or throw an exception) policy entries
for FilePermission objects that are relative, because I think they
can be a very dangerous thing...

> If so - the program below shows that it does not work (please take a look)!
>
> In general, I think that from a user's perspective that the different symbols
> should have the same meaning regardless of the permission. If I would for some
> reason like to choose all files in the current directory, and not recursivly on,
> '*' seems to be a good match. Users are used to '*', they will use it, and I
> don't think that changing the meaning of '*' for a specific permission is the
> correct approach.
>

The reason why we decided against using a single "*" is because we already
have two syntaxes:

- for recursive matches of all files
* for non-recursive matches of all files

It seems dangerous to me to have a single "*" suddenly mean something
recursive where it normally does not. Thus, a single "-" seems to be
a better fit, as "-" is wider in scope then "*". We are already forcing
users/admins to learn the difference between "/*" and "/-", and I think
they will quickly be come comfortable with the fact that "-" is more
powerful/dangerous then "*" because it is recursive. I'd hate to throw
a monkey-wrench into the picture and make a single "*" behave very different
then the normal use of a "*" . I actually thought about using "**" early on
instead of "-" i.e., "/tmp/**", "**", but no one liked that :-)

I have really never liked mixing in these special characters into the
filename namespace(especially without having away to quote them), but
I'm not sure if we have a better choice at this point. I would imagine
the release following 1.2 will have much better wildcard/re support.
(hopefully using a standard java wildcard/re package).

> For now - relative paths are enabled. I can see the potential danger in this,
> but since you enable a policy file in the invocation line, I can argue that this
> is acceptable.
> I doubt that a user that puts '*' and means a file named star. Moreover, if you
> put '-' (relative) it does not mean the file named '-': it has the recursive
> meaning, even without the '/'.
> So I think there is an inconsistency here !!!
>

I agree that its inconsistent. The point is "-" is treated special,
so it is never interpreted as relative. We could certainly make "*"
mean every file in the "current" directory if people want, however,
I think people would then expect/want "-" to mean every file in the
current directory, recursively! :-) That would require yet another
special case to handle the "all files everywhere" case that a
single "-" handles (which logically would be "--").

Thus it seems better to say that a single "-" means all files, and a single
"*" is not treated as special.

If people really want "-" and/or "*" wrt to the current directory
they can use "./*" or "./-" (and .\* .\- on win32 I think ;-)).

In any event I agree that this is another one of those confusing
areas that needs proper documentation and user education. Maybe
we'll get enough feedback and/or comments before FCS and change things.