Bug 226872 - TopSecurityManager add XStream to whitelist for sun.misc access.
TopSecurityManager add XStream to whitelist for sun.misc access.
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: Module System
7.2.1
PC All
: P3 (vote)
: TBD
Assigned To: Jaroslav Tulach
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-01 06:52 UTC by ah_mostin
Modified: 2014-07-21 14:54 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ah_mostin 2013-03-01 06:52:52 UTC
Xstream is a library which provides ability to serialize/deserialize java objects to/from XML. It does this through the use of sun.misc packages. In our NB 691 RCP based applications we had no issues with package but since migrating to NB721 we are now getting warnings and have no way to trap for or avoid them.

We have attempted to use the netbeans.security.nocheck parameter but the method that does the permission check (checkMemberAccess) in TopSecurityManager ignores this setting.

In the current design the only way to avoid the warning is add the calling class to the whitelist, this does appear to be a regular problem as libraries are found. Perhaps giving developers the ability to add to the whitelist might be a more extensible solution rather than having to push out new versions of the Class ?

I have also tried extending the TopSecurityManager class NB throws errors that the module containing my class is not a friend of the o.n.bootstrap module.
Comment 1 Antonin Nebuzelsky 2013-03-20 09:55:56 UTC
Jardo, what is the recommended approach?
Comment 2 Jaroslav Tulach 2013-03-26 08:56:18 UTC
We had terrible problems (~100 reported duplicates about completely broken IDE) with broken JaxWS libraries - that is why the defensive mode.

We could use branding to read the list of acceptable libraries. The only problem is that the o.n.bootstrap can't itself use NbBundle - the bundle would need to be injected into the system from core.startup module.
Comment 3 Jaroslav Tulach 2014-07-21 14:54:27 UTC
Seems to me that the current state (89ce8aec1248) of TopSecurityManager logs the messages only when executed with assertions on:

            if (caller != null && callerWhiteList.contains(caller.getName())) {
                l = Level.FINEST;
            } else {
                l = Level.FINE;
                assert (l = Level.INFO) != null;
            }

That is probably appropriate and there is no need for any changes, right?


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo