Par programme d'accorder des Autorisations sans l'aide de la politique de fichier

Procédure de programmation pour la subvention AllPermissions à un RMI application sans l'aide de la politique de fichier?

Mise à JOUR:

Après quelques recherches, j'ai écrit cette coutume de la Politique de Classe et installé via Policy.setPolicy(new MyPolicy()).

Maintenant, je reçois l'erreur suivante:

autorisation non valide: (java.io.FilePermission
\C:\eclipse\plugins\org.eclipse.osgi_3.7.0.v20110613.jar lire

class MyPolicy extends Policy {

    @Override
    public PermissionCollection getPermissions(CodeSource codesource) {
        return (new AllPermission()).newPermissionCollection();
    }

}

OriginalL'auteur Adel Boutros | 2012-07-31

Basé sur @EJP's conseils, j'ai de débogage à l'aide de -Djava.security.debug=access et a trouvé toutes les autorisations nécessaires dans un fichier de stratégie :

grant { permission java.net.SocketPermission "*:1024-", "se connecter,
résoudre"; };

grant { permission java.util.PropertyPermission "*", "lire, écrire";
};

grant { permission java.io.FilePermission "<>", "read";
};

Mais parce que je ne veux pas créer un fichier de stratégie, j'ai trouvé un moyen de répliquer par programme, par l'extension java.security.Policy classe et la définition de la politique au démarrage de mon application en utilisant Policy.setPolicy(new MinimalPolicy());

public class MinimalPolicy extends Policy {

    private static PermissionCollection perms;

    public MinimalPolicy() {
        super();
        if (perms == null) {
            perms = new MyPermissionCollection();
            addPermissions();
        }
    }

    @Override
    public PermissionCollection getPermissions(CodeSource codesource) {
        return perms;
    }

    private void addPermissions() {
        SocketPermission socketPermission = new SocketPermission("*:1024-", "connect, resolve");
        PropertyPermission propertyPermission = new PropertyPermission("*", "read, write");
        FilePermission filePermission = new FilePermission("<<ALL FILES>>", "read");

        perms.add(socketPermission);
        perms.add(propertyPermission);
        perms.add(filePermission);
    }

}

class MyPermissionCollection extends PermissionCollection {

    private static final long serialVersionUID = 614300921365729272L;

    ArrayList<Permission> perms = new ArrayList<Permission>();

    public void add(Permission p) {
        perms.add(p);
    }

    public boolean implies(Permission p) {
        for (Iterator<Permission> i = perms.iterator(); i.hasNext();) {
            if (((Permission) i.next()).implies(p)) {
                return true;
            }
        }
        return false;
    }

    public Enumeration<Permission> elements() {
        return Collections.enumeration(perms);
    }

    public boolean isReadOnly() {
        return false;
    }

}

Comme de Java8 vous pouvez simplifier implies à return perms.stream().anyMatch(it->it-implies(p));

OriginalL'auteur Adel Boutros

2

Parce que votre

nouveau AllPermission()).newPermissionCollection()

est traitée par Java comme immuable (pourquoi ajouter des autorisations à une collection qui permet déjà toutes les autorisations?), et parce que Java va essayer d'ajouter des autorisations à la collection. C'est là le message d'erreur vient de Java essayé d'ajouter un java.io.FilePermission à votre AllPermission.

Au lieu de cela, faire cela:
```
class MyPolicy extends Policy {
    @Override
    public PermissionCollection getPermissions(CodeSource codesource) {
        Permissions p = new Permissions();
        p.add(new PropertyPermission("java.class.path", "read"));
        p.add(new FilePermission("/home/.../classes/*", "read"));
        ... etc ...
        return p;
    }
}
```
En fait votre raisonnement est un peu sur la bonne voie. Mais ce n'est pas tout à fait vrai: Vérifier le code source de AllPermissions, par défaut, le (new AllPermission()).newPermissionCollection() renvoie une collection de permission qui renverra toujours false. C'est jusqu'à ce que vous ajoutez une instance de AllPermission.
Voici le lien pour le code source: grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/...

OriginalL'auteur WellINever
1

De ne pas installer le SecurityManager. Vous n'aurez besoin que si vous utilisez le code de fonction, et si vous avez besoin que vous avez besoin d'une bonne .la politique de fichier,

J'ai utiliser le code de fonction. Donc j'ai besoin d'elle. J'espérais pour remplacer le fichier de stratégie avec quelque chose comme une coutume java.security.Policy qui contient un AllPermissionCollection. Cela peut-il fonctionner de cette façon? et ce qui doit être changé pour le faire fonctionner?
Pouvez-vous voir mon edit s'il vous plaît?
Si vous êtes à l'aide de la base de code de fonction, vous ne voulez certainement pas à accorder AllPermission. Vous allez être en cours d'exécution de code à partir des anothe source. Vous avez besoin de construire un bon .fichier de stratégie qui accorde exactement les autorisations que vous pensez que le code téléchargé, et pas d'autres. Vous pouvez établir qu'avec un peu de helpmfr de -Djava.de sécurité.debug=accès,défaillance.
Je sais déjà comment créer un fichier de stratégie. Ce n'est pas ce que je veux parce que mon application est un Eclipse, vous ne pouvez donc pas ajouter un fichier de stratégie à un seul eclipse-plugin, vous devez l'ajouter à la eclipse.ini laquelle les clients vont trouver difficile à accepter
Vous n'avez pas le choix. Il n'y a aucun moyen de faire ce que vous voulez. En tout cas, je suggère que vos clients peuvent trouver encore plus difficile à accepter un RMI produit qui désactive toutes les fonctions de sécurité conçues en RMI, si c'était possible, qui, heureusement, il n'est pas. Ce que vous devriez faire est de donner le client, l'occasion de définir les autorisations, au lieu d'essayer d'échapper à la question et de briser le modèle de sécurité de Java.

OriginalL'auteur user207421

Court de solution

Étendre votre solution mise à jour:

public class MyPolicy extends Policy
{
    @Override
    public PermissionCollection getPermissions(CodeSource codesource)
    {
        Permissions p = new Permissions();
        p.add(new AllPermission());
        return p;
    }
}

Considérer, que Politique.getPermissions() doit toujours retourner une mutable PermissionCollection

Retourne: ...Si cette opération est prise en charge, le retour de l'ensemble des autorisations doit être un nouveau mutable exemple et il doit prendre en charge hétérogène types d'Autorisation...

Cette solution fonctionne déjà, car elle ajoute une AllPermission objet dans chaque appel de la Policy.getPermissions(ProtectionDomain), qui fait référence à Policy.getPermissions(CodeSource).

Propre solution

Mais il y a une solution plus propre, qui ne suit pas inutile, d'autres Autorisations, depuis AllPermissions permet assez déjà tout.

public class MyPolicy extends Policy
{
    private static class AllPermissionsSingleton extends PermissionCollection
    {
        private static final long serialVersionUID = 1L;
        private static final Vector<Permission> ALL_PERMISSIONS_VECTOR = new Vector<Permission>(Arrays.asList(new AllPermission()));

        @Override
        public void add(Permission permission)
        {
        }

        @Override
        public boolean implies(Permission permission)
        {
            return true;
        }

        @Override
        public Enumeration<Permission> elements()
        {
            return ALL_PERMISSIONS_VECTOR.elements();
        }

        @Override
        public boolean isReadOnly()
        {
            return false;
        }
    }

    private static final AllPermissionsSingleton ALL_PERMISSIONS_SINGLETON = new AllPermissionsSingleton();

    @Override
    public PermissionCollection getPermissions(CodeSource codesource)
    {
        return ALL_PERMISSIONS_SINGLETON;
    }
}

OriginalL'auteur Adam Taras

Vous devez vous connecter pour publier un commentaire.