So if my plugin has a SB that does some filesystem stuff, obviously I'm going to put these into liferay-plugin-package.properties file.

But if another plugin wants to use the services from the first plugin, does it also need the mentions in it's own liferay-plugin-package.properties file?

When you're doing something inside of the XxxLocalServiceImpl class, who's security manager is in charge?

It will have to declare the service dependency from the other plugin.

The other plugin's code will execute under it's own policy. This will be automatically calculated for you when using the generator (as long as your QA process causes the invocation of these operations, as it should).

My question is more along the lines of:

Portlet A uses SB and has a MyFileLocalServiceImpl class that reads/writes ${java.io.tmpdir}/myfile.xml. So in portlet A I add the security-manager-files-read and security-manager-files-write entries, and Portlet A's security manager is happy.

Now Portlet B uses the service from portlet A and calls the appropriate method on MyFileLocalServiceUtil. Portlet B's liferay-plugin-package.properties file will have the security-manager-services entry so that it can invoke the service from portlet A.

The question is, though, will portlet B also need to have the security-manager-files-read and security-manager-files-write privileges in order to actually invoke the service? When inside the method in MyFileLocalServiceImpl, which security manager is in effect when called from portlet B, is it B's security manager or A's?

No! The code of the plugin A (including it's services invoked by another plugin) is executing under it's own policy.

Great! Thanks for clarifying!

I was afraid that B's policy would be in effect and would need all of the same security stuff that is defined for A just to be able to invoke A's service (thereby exposing the fact that A is reading/writing ${java.io.tmpdir}/myfile.xml).