Community
Participate
Working Groups
Build Identifier: 2.1.0.M03-incubation After unzip of virgo the files often have Everyone (local or domain user). Running Virgo invokes jmxPermissions.vbs which does not set any permissions for org.eclipse.virgo.kernel.jmxremote.access.properties since the current user is not part of the ACL list. The problematic code seems to be: For Each ace in objSecurityDescriptor.DACL If ace.Trustee.Name = WshNetwork.UserName Then Set specificAce(0) = ace End If Next The Trustee.Name=Everyone, while UserName=<domain or local user> Perhaps a check if the user is included in a group could fix the issue. Unfortunately I don't have much experience with VBS, so my assumptions above may be wrong. Reproducible: Always Steps to Reproduce: 1. Unzip Virgo 2. Run startup.bat
We currently have a vbs which is Windows platform sensitive (and is a nightmare to maintain). This may be a Windows 7 specific problem -- we do not test on the W7 platform (yet). Can you identify the platform upon which you detect this problem, please?
I tested this also on Windows XP and Vista and the problem is present there also. I guess that this may be due to the domain configuration on my machines (Everyone domain group).
(In reply to comment #2) Thank you Hristo. This will be looked at in the next week or so, when our vbs/windows expert returns from the antipodes.
Just for the record - on a Windows machine outside a domain the script works OK. The jmx.properties file however has only one permissions and this is exactly the user that's trying to run Virgo.
I just tried to workaround the issue with a check for the groups: Set objUser = GetObject("WinNT://" & WshNetwork.UserDomain & "/" & WshNetwork.UserName) Dim specificAce(0) i = 0 For Each ace in objSecurityDescriptor.DACL If ace.Trustee.Name = WshNetwork.UserName Then Set specificAce(i) = ace WScript.Echo "Username = " & ace.Trustee.Name i = i + 1 Continue End If For Each oGroup in objUser.Groups WScript.Echo " Trustee = " & ace.Trustee.Name WScript.Echo " Group = " & oGroup.name If ace.Trustee.name = oGroup.name Then Set specificAce(i) = ace WScript.Echo "Username = " & ace.Trustee.Name i = i + 1 End If Next Next This doesn't seem to work since the group Everyone is not in the list of groups. This may happen if ActiveDirectory or some other user store is in use - I cannot tell the exact reason. Therefore as a solution I can propose the explicit setting of ACL to the one of the user that starts Virgo. In the end this is the purpose of the script. The problem of the current approach is that the desired ACL may not be present in the ACL list of the jmx properties file. There can be ACL for Everyone, Administrators or whatever group is set, but the user ACL may be absent. Therefore the script will just wipe out the ACL list which actually causes the problem.
I am verifying behaviour on Windows 7 Using virgo-web-server-2.1.0.M03-incubation org.eclipse.virgo.kernel.jmxremote.access.properties after running startup.bat (implicitly jxjPermissions.vbs) has no permissions and startup script fails with following error message Error: Exception thrown by the agent : java.io.FileNotFoundException: ...\config\org.eclipse.virgo.kernel.jmxremote.access.properties (Access is denied) I detected easily that indeed code in jmxPermissions.vbs is responsible but don't know how to fix it Tried to modify jmxPermissions.vbs by altering the following section Dim files(0) files(0) = "org.eclipse.virgo.kernel.jmxremote.access.properties" For Each file In files updateInheritance(configFolder & file) updateOwnership(configFolder & file) updatePermissions(configFolder & file) Next tried to place in remarks combinations of update... calls. finally server started but failed to access via http://localhost:8080. still, log reported tomcat started on port 8080 I hope this helps I will meanwhile try to discover a way to make jmxPermissions.vbs to work on as many versions of windows as possible I suspect WMI calls differ among different versions of Windows and Windows 7 is obviously a totally new case
Found something. On Windows 7 there are no instances of classes Win32_LogicalFileSecuritySetting (referenced in jmxPermissions.vbs) Used Microsoft "WMI Tools" to discover (WMI CIM Studio and WMI Object Browser) Trying to find alternative method plus a way to determine Windows version and act accordingly...
More observations Placed in remarks the "updateInheritance" and "updatePermissions" calls in jmxPermissions.vbs Server started normally and file org.eclipse.virgo.kernel.jmxremote.access.propertie permissions remained unaffected "updateInheritance" and "updatePermissions" calls make use of WMI "Win32_LogicalFileSecuritySetting" instance which does not exist in Windows 7 assumption on "Win32_LogicalFileSecuritySetting" was correct for Windows 7 Suspecting this could be a workaround for Windows 7 (not the best one however, still alternative to "Win32_LogicalFileSecuritySetting" plus O/S version check is required) failure to access http://localhost:8080 in "comment 6" was invalid, please ignore. Had to be typed as http://127.0.0.1:8080 instead (for unknown reasons)
As far as I was able to debug the issue the problem lies in the Sub: updatePermissions(configFolder & file) Commenting this sub seems to solve the problem on the affected systems. Perhaps changing the call for Windows 7 will do, but please note that I had the same problem on Vista. If you have a patch I can test it on XP, Vista and 7 in the domain configuration that caused the problem. What do you think of the idea to set explicit ACL? To me it looks better than cycling through all users and expecting that the current one will be already there (which proved to be false expectation).
Thanks Hristo. Chris is back tomorrow and will respond in due course, email backlog permitting.
We will investigate the feasibility of fixing this robustly for 2.1.0. If this cannot be done, we will document a workaround and look to fix this post 2.1.0.
The best compromise we could come up with was to tolerate the situation described in this bug and not attempt to set the file permissions in that case but to issue a warning instead and continue launching. If we can identify suitable robust/portable VBScript to create an ACE from scratch for the current user, we could use this instead of the current technique of searching for a suitable ACE in the file's permissions. However, we are not aware of such a VBScript technique which will work reliably across all Windows platforms. This will be fixed in the next milestone, but if you would like to try it out, I'll attach the updated script which needs to replace the one in the bin directory.
Created attachment 179447 [details] Fixed VBScript
Created attachment 179448 [details] cacls replacement for the VB script We can replace the VBS with 2 commands: takeown /F "%CONFIG_DIR%\org.eclipse.virgo.kernel.jmxremote.access.properties" > nul echo Y| cacls "%CONFIG_DIR%\org.eclipse.virgo.kernel.jmxremote.access.properties" /G "%USERDOMAIN%\%USERNAME%":F > nul The drawback from this approach is that the "takeown" does not exist in Windows XP and an error message is produced. Of course "takeown" can be removed since the main change here is the use of "cacls" command. I tested this approach on Windows XP and Windows 7. It works ok with domain users and also does restricts the access to the current user only (as expected)
(In reply to comment #14) > Created an attachment (id=179448) [details] > cacls replacement for the VB script Thanks Hristo. This change is a little more radical, perhaps risky, than my workaround. We'll review it and get back to you.
(In reply to comment #13) > Created an attachment (id=179447) [details] > Fixed VBScript I tested the workaround and Virgo was able to start without touching the properties.
(In reply to comment #15) > (In reply to comment #14) > > Created an attachment (id=179448) [details] [details] > > cacls replacement for the VB script > > Thanks Hristo. This change is a little more radical, perhaps risky, than my > workaround. We'll review it and get back to you. It turns out we used to use cacls but got burned. https://issuetracker.springsource.com/browse/DMS-456 shows a major weakness in cacls and prompted us to write the VBScript.
I agree - cacls is not usable. Perhaps we can try a hybrid approach then: - if icacls is available then we can use it - it overcomes the issue with echo by providing an /Y switch - if only cacls is on the system we can fallback to the VBS In this way the jmx properties will be protected at least on the newer Windows systems (2003 SP2, Vista, 7, 2008 ...). If older versions (2000, XP) are targeted then xcacls can be used as it also provides /Y switch
(In reply to comment #18) > I agree - cacls is not usable. > > Perhaps we can try a hybrid approach then: > - if icacls is available then we can use it - it overcomes the issue with echo > by providing an /Y switch > - if only cacls is on the system we can fallback to the VBS > > In this way the jmx properties will be protected at least on the newer Windows > systems (2003 SP2, Vista, 7, 2008 ...). > > If older versions (2000, XP) are targeted then xcacls can be used as it also > provides /Y switch It might be possible to get this kind of hybrid scheme to work, but I wouldn't relish the testing as it sounds like the execution path would vary depending on the Windows platform. Anyway, IMO such an approach is too risky for 2.1.0 as we'd want it to have plenty of time to "bed in", i.e. for users to try it and raise feedback. Can we agree to stick with the current workaround for 2.1.0 and revisit alternatives post 2.1.0 (possibly under a new enhancement bug for clarity)?
(In reply to comment #19) > (In reply to comment #18) > > I agree - cacls is not usable. > > > > Perhaps we can try a hybrid approach then: > > - if icacls is available then we can use it - it overcomes the issue with echo > > by providing an /Y switch > > - if only cacls is on the system we can fallback to the VBS > > > > In this way the jmx properties will be protected at least on the newer Windows > > systems (2003 SP2, Vista, 7, 2008 ...). > > > > If older versions (2000, XP) are targeted then xcacls can be used as it also > > provides /Y switch > > It might be possible to get this kind of hybrid scheme to work, but I wouldn't > relish the testing as it sounds like the execution path would vary depending on > the Windows platform. > > Anyway, IMO such an approach is too risky for 2.1.0 as we'd want it to have > plenty of time to "bed in", i.e. for users to try it and raise feedback. > > Can we agree to stick with the current workaround for 2.1.0 and revisit > alternatives post 2.1.0 (possibly under a new enhancement bug for clarity)? Sure - 2.1.0 is prio 1. Let's leave the acl modifications for the next versions so we can have enough time to experiment and get feedback. Perhaps we can just describe the steps needed to secure the jmx properties file . Can the current troubleshooting page be reused for this purpose?
(In reply to comment #20) > Sure - 2.1.0 is prio 1. Let's leave the acl modifications for the next versions > so we can have enough time to experiment and get feedback. Agreed. > > Perhaps we can just describe the steps needed to secure the jmx properties file > . Can the current troubleshooting page be reused for this purpose? Yes that sounds good. I am not aware of the necessary steps, so if you are, please could you update the wiki or provide text here that we could use. Thanks.
(In reply to comment #21) > (In reply to comment #20) > > Sure - 2.1.0 is prio 1. Let's leave the acl modifications for the next versions > > so we can have enough time to experiment and get feedback. > > Agreed. > > > > > Perhaps we can just describe the steps needed to secure the jmx properties file > > . Can the current troubleshooting page be reused for this purpose? > > Yes that sounds good. I am not aware of the necessary steps, so if you are, > please could you update the wiki or provide text here that we could use. > Thanks. I updated the Windows troubleshooting section in the documentation. The patch is attached to bug 326140
RC1 is planned instead of milestone 5.
Closing now that documentation is in place. A new bug will be required for a later release if it is necessary to replace the VBScript with cacls etc.
If you're gonna close it, then close it!
Well spotted!
