Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[p4-feedback] UAC privilege escalation

Visser, Dale dvisser at
Thu Nov 3 16:37:53 PDT 2011


Thanks for putting it in the issue tracker. I got myself a login, so I could monitor the item. My system is running 64-bit Windows 7 Professional SP1. I think the third possible resolution you suggested is the most elegant, i.e., catching the specific permission exception and retrying with a user plugins folder. It requires the least thought from the normal Windows user, but in the (I assume) rare case of a multi-user Windows system with Protégé installed for all users, allows an admin to install plugins to be available for all users.

Best regards,

From: p4-feedback-bounces at [mailto:p4-feedback-bounces at] On Behalf Of Timothy Redmond
Sent: Thursday, November 03, 2011 4:08 PM
To: p4-feedback at
Subject: Re: [p4-feedback] UAC privilege escalation

I also have a security background and I think that this should be fixed.  I have made a GForge for this issue (  I am not sure why Protege is using extra privileges but, aside from the plugin installation/upgrade isssue, I can't think of a reason why it should need privilege.  We have run read-only Protege installations on unix machines without problems.  I will look into this and I will see if I can see a good solution to the plugin install/upgrade issue as well.

Could you help me complete the bug report by letting me know the exact version of windows that you are using?


On 10/31/2011 01:19 PM, Visser, Dale wrote:

So far, Protégé seems to work just fine with limited user privileges. However, I haven’t really tried a lot of different tasks with it. There’s always the possibility that some corner of the application or one of its plugins will have only been tested with administrator privileges. I will post to the list if I hit any issues. If there’s a unit test suite, it would be useful to run the full suite on a Windows OS in a limited user context.

As a test, I just had your InstallAnywhere installer put Protégé 4.2α directly into %USERPROFILE%\bin\Protege_4.2_alpha. Even when I do that, Protégé.exe still insists on UAC privilege escalation before it will launch.

Due to my background worrying about the security aspects of software, I tend to obsess about running with the minimum possible privileges. As I described in my previous post, I’ve found a “pure java batch script” workaround that lets me do that with Protégé. Thanks for letting me put in my 2¢ about this. I understand that it almost certainly takes a back burner relative to the addition of new OWL-related functionality.

Best regards,
From: p4-feedback-bounces at<mailto:p4-feedback-bounces at> [mailto:p4-feedback-bounces at] On Behalf Of Timothy Redmond
Sent: Monday, October 31, 2011 1:45 PM
To: Submit feedback for Protege 4.x
Subject: Re: [p4-feedback] UAC privilege escalation

I did know that if you want to update or install a plugin into a read protected copy of Protege then you will need administrative privilege.  This seems reasonable as you are making an administrative change to Protege that will be seen by all users.  If the intent was that Protege would only be used by one user, then you can get around this by installing Protege to an unprotected user area.

We did have the idea that we could have a separate plugin area for user upgrades.  This does create a series of problems that we would then need to consistently solve (how to deal with conflicts between user installed plugins and protege plugins, which plugins get priority, etc).  I am not currently sure how these problems should be solved.  Most applications work with this by temporarily escalating privilege at the point where the new functionality is introduced.  But I don't know if there is a portable way to do this.

Outside of installing and updating plugins, are you having trouble with Protege in user mode?


On Oct 31, 2011, at 7:19 AM, Visser, Dale wrote:

I looked at the console window that Protégé.exe launches, and realized I could just copy the commands issued there into a batch file. I’ve attached two log files of the same session. One is the log file that Protégé created in %USERPROFILE%\.Protege, and the other is just a copy and paste of my console window text. In the session, I did the following:

1.       Launched Protégé
2.       Loaded CVE_PUBS.owl
3.       Attempted to install a plugin (Browser View)

An access-denied IOException is thrown at Method). I think this supports my theory that the only reason Administrative privileges are being required by Protégé.exe is that plugins are getting installed under %PROGRAMFILES%, an area restricted to be read-only without Administrative privileges.

I verified that I can solve the issue for myself by copying the %PROGRAMFILES%\Protege_4.1 to %USERPROFILE%\bin\Protege_4.1 and modifying my batch file to cd to that folder instead before invoking the java.exe command line. I was then able to install the Protégé plugin with no issues.

Assuming that is the only reason that Administrative privileges are ever needed by Protégé, I recommend making the plugins a user-level thing in a future version.  Likely, that would mean moving the plugins folder under ~/.Protege instead of under the program folder. Then Protégé.exe would never need to run as an Administrator, which is more secure for the user.

From: p4-feedback-bounces at<mailto:p4-feedback-bounces at> [mailto:p4-feedback-bounces at]<mailto:[mailto:p4-feedback-bounces at]> On Behalf Of Visser, Dale
Sent: Sunday, October 30, 2011 2:44 PM
To: p4-feedback at<mailto:p4-feedback at>
Subject: [p4-feedback] FW: UAC privilege escalation


Thanks for your reply. I am using Protégé 4.1. I took a look and can see a .Protege folder under %USERPROFILE% (the Windows equivalent of the Unix ~). In that folder is log files from my last 7 Protégé sessions. I agree that Java user preferences should not be cause for needing admin privileges.

Unfortunately, my Java-Fu is rusty, so I don’t know how to get around using Protégé.exe to start the application. If I answer “No” to the UAC elevation prompt, the application simply doesn’t launch. If you told me what jar files need to be in the classpath, and what the name of the main class is, I could try launching Protégé manually using java.exe.

Best regards,
Dale Visser

> What version of Protégé are you using?  I thought that admin privileges were not necessary in Protégé 4.1 (e.g. in particular in the latest release).  We already have checks in Protégé for the
> operating system (though the main reason for platform specific code is the mac platform).  The Protégé application data files end up in ~/.Protégé (which is probably not an ideal spot on
> windows but it is reasonable on Unix systems including the mac).  The protégé application also modifies the user java preferences but I thought that this was also ok.
> Do you have a stack trace for the error when you run the program in user mode?  I will see if I can find a windows system to check this sometime this week.

From: Visser, Dale
Sent: Sunday, October 30, 2011 1:54 PM
To: 'p4-feedback at<mailto:%27p4-feedback at>'
Subject: UAC privilege escalation

This is a question for the Protégé application and installer developers about the Windows version: Why do I need to elevate to Admin privileges with a UAC prompt when I run Protégé.exe?

Is it because plugins get installed in /plugins under the Program folder? If so, wouldn’t it be better to use %AppData%\Protege_4.1 as the location to stick plugin jar files, since that is accessible to even a non-privileged user?

I realize this would require a bit of coding effort to include a function like

        static boolean isWindows(){
            String os = System.getProperty("<>").toLowerCase();
            return (os.indexOf( "win" ) >= 0);

and change code in probably several areas to use %AppData% for the plugin path instead. The benefit is the removal of an annoying UAC prompt, and an application that is usable within a more secure “sandbox”.

Best regards,
Dale  Visser

p4-feedback mailing list
p4-feedback at<mailto:p4-feedback at>


p4-feedback mailing list

p4-feedback at<mailto:p4-feedback at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the p4-feedback mailing list