java - sistema - ¿Cómo copiar datos automáticamente a nuevos hilos de RMI?

sistema bancario en php y mysql

Question

Estoy adaptando una pequeña aplicación rmi de cliente-servidor. He escrito varias cosas:

HelloInterface -> A Hello World interface for RMI
Server -> The server app''
Client -> The client app''

Nada especial, pero ... He puesto mis manos en un nuevo RMISecurityManager, que llama a un método JNI y verifica el permiso para un usuario diferente:

package rmi;
import java.rmi.RMISecurityManager;
import java.io.*;
public class NativeRMISecurityManager extends RMISecurityManager
{
private boolean unix;
protected static ThreadLocal user = new ThreadLocal();
/*
* On interdit l''utilisation du constructeur par defaut
* pour obliger l''utilisation du constructeur avec user.
*/
private NativeRMISecurityManager()
{
super();
}
public NativeRMISecurityManager (final String user)
{
super();
String OS = System.getProperty("os.name").toLowerCase();
unix = (OS.compareTo("windows") != 0); /* Assume that if not
* windows, then "UNIX/POSIX"
*/
/*
* ThreadLocal''s user : Each thread is considered
* to have different access rights to the machine
*/
NativeRMISecurityManager.user.set(user);
if (!unix)
{
System.out.println("Systeme : "+OS);
}
}
public void checkRead(String file)
{
super.checkRead(file);
/*
* If we are on a **IX platform we want to check that
* the _user_ has access rights.
*/
if (unix)
{
String str_user = (String)NativeRMISecurityManager.user.get();
if (file == null)
{
throw new SecurityException("file = NULL !!!");
}
if (str_user == null)
{
throw new SecurityException("user = NULL in the ThreadLocal!!!");
}
int ret = c_checkRead(
file,
str_user
);
if (ret != 0)
{
throw new SecurityException("Access error: " + file);
}
}
}
public native int c_checkRead(String file, String user);
}

En la clase Servidor, estoy haciendo eso:

String user = "my_user";
System.setSecurityManager(new NativeRMISecurityManager(user));

Esta clase parece funcionar en el hilo principal del Servidor. Ahora el problema es cuando trato de conectarme a esa clase de Servidor y buscar el Registro. Obtengo esa excepción:

Exception in thread "RMI TCP Connection(1)-192.168.42.207" java.lang.ExceptionInInitializerError
at sun.rmi.transport.StreamRemoteCall.getInputStream(StreamRemoteCall.java:111)
at sun.rmi.transport.Transport.serviceCall(Transport.java:118)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.SecurityException: user = NULL dans le ThreadLocal!!!
at rmi.NativeRMISecurityManager.checkRead(NativeRMISecurityManager.java:62)
at java.io.File.exists(File.java:700)
at java.lang.ClassLoader$3.run(ClassLoader.java:1689)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1686)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.server.MarshalInputStream.<clinit>(MarshalInputStream.java:97)
... 5 more

En mi humilde opinión, el significado de esto es que un subproceso se crea (implícitamente) y obtiene NativeRMISecurityManager como su SecurityManager predeterminado.

¿Alguien tiene algún consejo sobre eso?

Answer 1

En mi humilde opinión, el significado de esto es que un subproceso se crea (implícitamente) y obtiene NativeRMISecurityManager como su SecurityManager predeterminado.

Esto es cierto, aunque no es la causa de su error; el problema tiene que ver con el uso de ThreadLocal. La propiedad clave de un ThreadLocal es que cada hilo de llamada tiene su propio valor. En este caso, "usuario" está siendo configurado por (y para) el hilo que inicializa el NativeRMISecurityManager y lo configura como el Administrador de seguridad del sistema (presumiblemente el hilo principal).

Sin embargo, otro hilo (por el aspecto del hilo de gestión de mensajes RMI) llama a checkRead (), pero el campo "usuario" nunca se estableció para este hilo. Por lo tanto, el valor vuelve como nulo.

A menos que exista alguna razón para que diferentes hilos tengan valores diferentes, y no puedo distinguir uno de tu ejemplo, recomendaría hacer que el campo "usuario" a) sea un String, no un ThreadLocal yb) no estático. Eso debería resolver su problema de valor nulo.

Sin embargo, suponiendo que se trata de una restricción de requisito / diseño, el problema con la arquitectura actual es que solo el hilo que crea la instancia de NativeRMISecurityManager realmente tiene un usuario: cada otro hilo obtiene nulo.

Al profundizar en esto con un poco más de profundidad, creo que necesito una mejor comprensión de su dominio de problema para ofrecer sugerencias útiles en cuanto a una solución. Además, no hay nada rápido o sucio en la arquitectura de seguridad de Java. Sin embargo, haré mi mejor trabajo bajo algunas suposiciones:

1. Se supone que los hilos creados por el sistema son de confianza
2. Los hilos creados por su código deben especificar un usuario
3. Los hilos secundarios deberían heredar al usuario del hilo de creación

Posible implementación:

public class NativeRMISecurityManager extends RMISecurityManager {
private static final boolean UNIX;
static {
String OS = System.getProperty("os.name").toLowerCase();
UNIX = (OS.compareTo("windows") != 0); /* Assume that if not
* windows, then "UNIX/POSIX"
*/
}
protected static InheritableThreadLocal<String> user =
new InheritableThreadLocal<String>();
public static setThreadUser(String username) {
user.set(username);
}
public NativeRMISecurityManager(String initialUser) {
super();
// Set the user for the thread that constructs the security manager
// All threads created as a child of that thread will inherit the user
// All threads not created as a child of that thread will have a ''null'' user
setThreadUser(initialUser);
}
public void checkRead(String file) {
super.checkRead(file);
/*
* If we are on a **IX platform we want to check that
* the _user_ has access rights.
*/
if (UNIX)
{
if (file == null)
{
throw new SecurityException("file = NULL !!!");
}
String str_user = NativeRMISecurityManager.user.get();
if (str_user != null)
{
// Note: sanitize input to native method
int ret = c_checkRead(file, str_user);
if (ret != 0)
{
throw new SecurityException("Access error: " + file);
}
}
// Assume a system thread and allow access
}
}
public native int c_checkRead(String file, String user);
}

Answer 2

¡Sí! Eso es.

Lo pensé ayer por la tarde, y seguí con la misma solución. Publicaré aquí mi código para aquellos que tengan curiosidad de eso. 1) NativeRMISecurityManager 2) El código C (tiene que generar el .h con javah

(nb: No lo traduciré en inglés ya que hay muchos comentarios en francés)

package rmi;
import java.rmi.RMISecurityManager;
/**
* <p> Ce SecurityManager, qui herite de RMISecurityManager,
* implemente une verification supplementaire des droits
* d''acces aux fichiers.
* A la creation du SecurityManager et lors de la creation
* de nouveaux threads, on renseigne ThreadLocal du nom du
* _user_ du thread.
* <p>Ainsi, lors des checkRead() et checkWrite()
* notre SecurityManager appelle une methode native (JNI)
* qui va verifier directement si le user a les droits
* d''acces a la ressource.
* <p><b>Warning : NE PAS OUBLIER DE FAIRE APPEL A
* setCurrentUser() DANS CHAQUE THREAD CREE.</b>
* <p> <b>Remarque :</b> Pour les informations sur la compilation
* et l''execution de la lib ecrite en C, cf. le fichier README.
* @author a_po
*/
public class NativeRMISecurityManager extends RMISecurityManager
{
private boolean unix;
protected ThreadLocal user = new ThreadLocal();
/**
* Constructeur par defaut.
* <p><b>ATTENTION :</b> Bien faire appel a la methode setCurrentUser(String) !
* Sinon le SecurityManager se comportera comme un RMISecurityManager classique.
* @see public void setCurrentUser(String userName)
*/
public NativeRMISecurityManager()
{
super();
String OS = System.getProperty("os.name").toLowerCase();
unix = (OS.compareTo("windows") != 0); /* Si le systeme
* n''EST PAS windows,
* alors c''est UNIX...
*
* Pas tres rigoureux,
* mais sinon il faut tester
* Systeme V, Linux, *BSD,
* Sun OS, ...
*/
/*
* User du ThreadLocal : Chaque thread est considere comme ayant des
* droits d''acces au systeme potentiellement differents.
*/
this.user.set(user);
if (!unix)
{
System.out.println("Systeme : "+OS);
}
}
/**
* Verification en lecture.
* <p>
* Dans le cas ou l''on est sur une plateforme POSIX,
* on souhaite verifier que le _user_ du Thread a le droit
* de lecture sur le fichier.
* <p>
* De plus, dans le cas ou user est null, cela signifie
* OBLIGATOIREMENT que le thread a ete cree "automatiquement"
* et que le thread courant n''est pas un thread de "tache a executer".
* <p>
* En effet, le user est recupere dans le ThreadLocal
* et on force l''initialisation de cette variable a l''instanciation
* du SecurityManager (en mettant le constructeur par defaut prive) ou
* en faisant appel a setCurrentUser(String)
* @see void rmi.NativeRMISecurityManager.setCurrentUser(String user)
*/
public void checkRead(String file)
{
super.checkRead(file);
String str_user = (String)this.user.get();
if (unix && str_user != null)
{
if (file == null)
{
throw new SecurityException("file = NULL !!!");
}
int ret = c_checkRead(file, str_user);
if (ret != 0)
{
throw new SecurityException("Erreur d''acces au fichier : " + file);
}
}
}
/**
* Verification d''acces en ecriture sur un fichier.
* @see void rmi.NativeRMISecurityManager.checkRead(String file)
*/
public void checkWrite(String file)
{
super.checkWrite(file);
String str_user = (String)this.user.get();
if (unix && str_user != null)
{
if (file == null)
{
throw new SecurityException("file = NULL !!!");
}
int ret = c_checkWrite(file, str_user);
if (ret != 0)
{
throw new SecurityException("Erreur d''acces au fichier : " + file);
}
}
}
/**
* Configure le thread courant pour que le user soit pris en compte
* dans les verifications d''acces aux fichiers.
* @param user
*/
public void setCurrentUser(String userName)
{
this.user = new ThreadLocal();
this.user.set(userName);
}
public String getCurrentUser()
{
if (user!=null){
return (String)user.get();
}
else return null;
}
/**
* Methode native a implementer en C.
* @param file
* @param user
* @return 0 si ok <p> -1 sinon
*/
public native int c_checkRead(String file, String user);
/**
* Idem que pour c_checkRead
* @param file
* @param user
* @return
* @see int rmi.NativeRMISecurityManager.c_checkRead(String file, String user)
*/
public native int c_checkWrite(String file, String user);
/**
* Chargement de la bibliotheque JNI.
*/
static
{
System.loadLibrary("rmi_NativeRMISecurityManager");
}
}

Y la biblioteca C:

#include <stdio.h>
#include <jni.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <pwd.h>
#include <stdlib.h>
#include <grp.h>
#include <string.h>
#include "rmi_NativeRMISecurityManager.h"
/* Droits en lecture / ecriture / execution */
#define R_RIGHT 4
#define X_RIGHT 1
#define W_RIGHT 2
JNIEXPORT jint JNICALL Java_rmi_NativeRMISecurityManager_c_1checkRead
(JNIEnv *env, jobject obj, jstring file, jstring user)
{
int ret = check_permission(env, obj, file, user);
/**
* La permission d''acces a un fichier vaut ceci :
* 1 pour l''execution
* 2 pour l''ecriture
* 4 pour la lecture.
* Donc :
* * Droit en lecture : 4, 5, 6, 7
* * Droit en ecriture : 2, 3, 6, 7
* * Droit en execution : 1, 3, 5, 7.
*/
if (ret == R_RIGHT || ret == R_RIGHT + W_RIGHT ||
ret == R_RIGHT + X_RIGHT || ret == R_RIGHT + W_RIGHT + X_RIGHT)
{
return 0;
}
else
return -1;
}
JNIEXPORT jint JNICALL Java_rmi_NativeRMISecurityManager_c_1checkWrite
(JNIEnv *env, jobject obj, jstring file, jstring user)
{
int ret = check_permission(env, obj, file, user);
/**
* La permission d''acces a un fichier vaut ceci :
* 1 pour l''execution
* 2 pour l''ecriture
* 4 pour la lecture.
* Donc :
* * Droit en lecture : 4, 5, 6, 7
* * Droit en ecriture : 2, 3, 6, 7
* * Droit en execution : 1, 3, 5, 7.
*/
if (ret == W_RIGHT || ret == W_RIGHT + R_RIGHT ||
ret == W_RIGHT + X_RIGHT || ret == W_RIGHT + R_RIGHT + X_RIGHT)
{
return 0;
}
else
return -1;
}
int check_permission(JNIEnv *env, jobject obj, jstring file, jstring user)
{
struct stat pstat;
const char* pzcfile = (*env)->GetStringUTFChars(env, file, 0);
const char* pzcuser = (*env)->GetStringUTFChars(env, user, 0);
struct passwd* puserInfo;
int bisOwner = 0;
int bisGroup = 0;
struct group* pgroupInfo;
int i;
int droits = 0;
/* recuperer les informations relatives au fichier */
if(lstat(pzcfile, &pstat)<0)
{
fprintf(stderr,"* Le fichier %s n''exite pas./n", pzcfile);
(*env)->ReleaseStringUTFChars(env, file, pzcfile);
(*env)->ReleaseStringUTFChars(env, user, pzcuser);
return -1;
}
/* recuperer l''identifiant du user */
puserInfo = getpwnam(pzcuser);
if(puserInfo == NULL)
{
fprintf(stderr,"* L''utilisateur %s n''est pas connu du systeme./n", pzcuser);
(*env)->ReleaseStringUTFChars(env, file, pzcfile);
(*env)->ReleaseStringUTFChars(env, user, pzcuser);
return -2;
}
/* regarder si le user est proprietaire du fichier */
if(puserInfo->pw_uid == pstat.st_uid)
{
bisOwner = 1;
}
/* si le user n''est pas proprietaire, verifier s''il est membre du groupe */
if(!bisOwner)
{
/* recuperer les informations relatives au groupe */
pgroupInfo = getgrgid(pstat.st_gid);
/* parcourir la liste des membres du groupe a la recherche du user */
for(i=0;;i++)
{
if(pgroupInfo->gr_mem[i] == NULL)
{
break;
}
if(strcmp(pgroupInfo->gr_mem[i],pzcuser) == 0)
{
bisGroup = 1;
break;
}
}
}
/* recuperer les droits correspondants au user */
if(bisOwner)
{
droits = (pstat.st_mode & S_IRWXU) >> 6;
}
else if(bisGroup)
{
droits = (pstat.st_mode & S_IRWXG) >> 3;
}
else
{
droits = pstat.st_mode & S_IRWXO;
}
/* liberer les espaces memoire alloues */
(*env)->ReleaseStringUTFChars(env, file, pzcfile);
(*env)->ReleaseStringUTFChars(env, user, pzcuser);
return droits;
}

Muchas gracias, Greg Case. Esto me consuela porque hemos encontrado la misma solución. :)