I’d go back to the trace log, particularly from the PERMISSION_MGMT source. At its most verbose setting it is pretty in-depth about going through each access control check, and should say where something is happening to cause permission denied.
From: George Tang [mailto:[email protected]] Sent: Tuesday, October 25, 2016 1:20 PM To: Kevin Kane <[email protected]> Cc: allseen-core <[email protected]> Subject: Re: [Allseen-core] API change Hi Kevin, I was able to get a signed manifest by the permission configurator. I'm now back to the same problem of having ER_PERMISSION_DENIED when calling reset. Is there anything else that I can check for to make sure I'm not doing something wrong? The signed manifest returned was, so I don't think this is a part of the issue anymore: <manifest> <version>1</version> <rules> <node name="*"> <interface name="*"> <method name="*"> <annotation name="org.alljoyn.Bus.Action" value="Provide"/> <annotation name="org.alljoyn.Bus.Action" value="Modify"/> </method> <signal name="*"> <annotation name="org.alljoyn.Bus.Action" value="Provide"/> <annotation name="org.alljoyn.Bus.Action" value="Observe"/> </signal> <property name="*"> <annotation name="org.alljoyn.Bus.Action" value="Provide"/> <annotation name="org.alljoyn.Bus.Action" value="Observe"/> <annotation name="org.alljoyn.Bus.Action" value="Modify"/> </property> </interface> </node> </rules> <thumbprint> <oid>2.16.840.1.101.3.4.2.1</oid> <value>M2M2ZmFhNmEzODgyNGNkYWZmOWZiMmZhODAxNTJlYTdiODEyOTBhYjkxOTA0MmJj YmNhNmUyY2FmZWEzZTliOQ==</value> </thumbprint> <signature> <oid>1.2.840.10045.4.3.2</oid> <value>YzRiZjBiY2UxNDNmNzY1NzJjY2Y5ZTJiNDZjOWU0OTgxMWU2N2U5OTAwZjFmYTg1 MzljMGU3NmVkMDY0NzIzYWU1MzNiZDY5OTE0NmQxNzdhMWY1ZTg2NWE4MjI2N2Yx MjkzZDQxYTAyZmI2MjM4M2NmNmQxZTEyOWEyMDE3NDk=</value> </signature> </manifest> On Tue, Oct 25, 2016 at 10:29 AM, Kevin Kane <[email protected]<mailto:[email protected]>> wrote: It should be possible to call the XmlManifestConverter from inside the JNI code, to do the conversion between XML and Manifest object there, before calling the C++ API. We did something like this for the C API in alljoyn_c\src\SecurityApplicationProxy.cc. This is another option if we don’t want to add an XML-using API to C++. Regardless, since it seems natural to use a bus attachment as a key container in a security manager, and we already have APIs for signing certificates with the bus attachment’s private key, I think it makes sense to expose similar functionality for manifests in the Java layer. I also agree with not exposing CredentialAccessor. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of George Tang Sent: Monday, October 24, 2016 10:35 PM To: allseen-core <[email protected]<mailto:[email protected]>> Subject: [Allseen-core] API change Hi, I have discussed with Kevin Kane an API change to core. I would like to add another version of ComputeThumbprintAndSignManifest to PermissionConfigurator that takes a xml string instead of a manifest object. XmlManifestConverter is not public, so it may not be conventionally accessible from the Java bindings. I could use include "../../../alljoyn_core/src/XmlManifestConverter.cc" but I'm sure this is not good practice. This issue blocks the java bindings from being able to call Reset, StartManagement, EndManagement successfully. Another solution that doesn't change the c++ API would be making a public function in java to get the busAttachment's private Key. This would be inconsistent with the c++ bindings in that c++ doesn't expose this. I haven't started work on it, but from my investigation, I think it will take me 8 additional hours not including the code review process.
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
