4

Is it possible to implement a wrapper application for other (Java) applications using Java?

The purpose is to enforce usage policies for documents independent of the application used to work with a specific document.

E.G. I have an encrypted file that needs to be decrypted and opened in some kind of editor. So the wrapper application would decrypt the file and start the editor within itself to enforce an read-only policy by denying the write-access to the application, for example. Therefore the Runtime.getRuntime().exec(<command>) method doesn't fit well :)

There are also some ways to intercept method invocations within the same application but none that would wrap a whole other application.

I've also read about altering the JVM itself to intercept the file access. That sounds pretty good. But I need to dynamically change the policy depending on a user. That might not work as far as I know by now.

I guess there might not be any way to do this using Java code, but I'd appreciate any kind of hints and help.

Kai
  • 38,985
  • 14
  • 88
  • 103
bandt
  • 41
  • 1
  • Why does the application need to be a 'wrapper' application? I'd think you'd be able to implement this type of requirement using the eclipse RPC. You'd just have to disable the ability to save in your code by disabling any particular save functions the Eclipse RPC editor provides. – aglassman Jun 07 '12 at 13:58
  • I was thinking of a wrapper application, because i thought of an more generic approach to the problem. I guess using Eclipse RPC would require to write my own Editor. Or did I get that wrong? That's not exactly what i'm looking for in first place. Sorry if I didn't get that clear before. It would be nice to leave the joice of the editor for example for a .txt file to the user but leave the control to the file access to my application. – bandt Jun 07 '12 at 15:07
  • Eclipse RPC has a built in editor, and also built in file browsers. I think it would fit your project well. – aglassman Jun 07 '12 at 15:08
  • I do see your point of leaving the choice of the editor to the user, but may be more trouble than it's worth IMO. – aglassman Jun 07 '12 at 15:10
  • Trouble it is. :) But that's kind of the point about it. ;) I'm working on a prototype of a DLP system and like to have any kind of documents be supported by the rights management. THX for your comments by the way. – bandt Jun 07 '12 at 17:59

2 Answers2

2

I've also read about altering the JVM itself to intercept the file access. That sounds pretty good. But i need to dynamically change the policy depending on a user.

Set a custom SecurityManager that overrides checkWrite(String) to throw an exception.

Here is a simple example that prevents child frames from exiting the VM (checkExit(int)).

import java.awt.GridLayout;
import java.awt.event.*;
import java.security.Permission;
import javax.swing.*;

/** NoExit demonstrates how to prevent 'child' applications from 
 * ending the VM with a call to System.exit(0). */
public class NoExit extends JFrame implements ActionListener {

    JButton frameLaunch = new JButton("Frame");
    JButton exitLaunch = new JButton("Exit");

    /** Stores a reference to the original security manager. */
    ExitManager sm;

    public NoExit() {
        super("Launcher Application");

        setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);

        sm = new ExitManager( System.getSecurityManager() );
        System.setSecurityManager(sm);

        setLayout(new GridLayout(0,1));

        frameLaunch.addActionListener(this);
        exitLaunch.addActionListener(this);

        add( frameLaunch );
        add( exitLaunch );

        pack();
        setSize( getPreferredSize() );
        setLocationByPlatform(true);
    }

    public void actionPerformed(ActionEvent ae) {
        if ( ae.getSource()==frameLaunch ) {
            TargetFrame tf = new TargetFrame();
        } else {
            // change back to the standard SM that allows exit.
            System.setSecurityManager(
                    sm.getOriginalSecurityManager() );
            // exit the VM when *we* want
            System.exit(0);
        }
    }

    public static void main(String[] args) {
        NoExit ne = new NoExit();
        ne.setVisible(true);
    }
}

/** Our custom ExitManager does not allow the VM to exit, but does 
 * allow itself to be replaced by the original security manager. */
class ExitManager extends SecurityManager {

    SecurityManager original;

    ExitManager(SecurityManager original) {
        this.original = original;
    }

    /** Deny permission to exit the VM. */
    public void checkExit(int status) {
        throw( new SecurityException() );
    }

    /** Allow this security manager to be replaced,
  if fact, allow pretty much everything. */
    public void checkPermission(Permission perm) {
    }

    public SecurityManager getOriginalSecurityManager() {
        return original;
    }
}

/** This example frame attempts to System.exit(0) on closing, we must 
 * prevent it from doing so. */
class TargetFrame extends JFrame {

    TargetFrame() {
        super("Close Me!");
        add(new JLabel("Hi!"));

        addWindowListener( new WindowAdapter() {
            public void windowClosing(WindowEvent we) {
                System.out.println("Bye!");
                System.exit(0);
            }
        });

        pack();
        setSize( getPreferredSize() );
        setLocationByPlatform(true);
        setVisible(true);
    }
}
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
0

The Eclipse RPC may be a good option to look at. It provides editor views which can easily be changed to enable / disable save, and other functionality at run time. Since Eclipse is written in Java, most Java code you already have will play nice with the framework.

aglassman
  • 2,643
  • 1
  • 17
  • 30