enabled security manager, now I get a ClassNotFoundException at deploy time and the app is unusable. Happens with 6.1.1 and 6.1.20. How can I resolve this?

INFO: Deploying web application directory /Users/trapp/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/zsign-user-config-portlet
17:09:15,599 ERROR [pool-2-thread-3][PortalServiceChecker:249] java.lang.ClassNotFoundException: com.liferay.portal.service.ResourcePermissionLocalServiceUtil
java.lang.ClassNotFoundException: com.liferay.portal.service.ResourcePermissionLocalServiceUtil
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.liferay.portal.security.pacl.checker.PortalServiceChecker.touchService(PortalServiceChecker.java:242)
...

Here are my security settings:
security-manager-enabled=true
security-manager-expando-bridge=com.liferay.portal.model.User
#security-manager-services[ WTF to put here for doc library????? ]=\
# com.liferay.portlet.documentlibrary.service.DLAppServiceUtil, \
# com.liferay.portlet.documentlibrary.service.DLAppLocalServiceUtil,\
# com.liferay.portlet.documentlibrary.service.DLFileEntryLocalServiceUtil, \
# com.liferay.portlet.documentlibrary.service.DLFolderLocalServiceUtil, \
# com.liferay.portlet.expando.service.ExpandoColumnLocalServiceUtil,\
# com.liferay.portlet.expando.service.ExpandoTableLocalServiceUtil
security-manager-services=\
com.liferay.portal.service.GroupLocalService, \
com.liferay.portal.service.ResourcePermissionLocalService,\
com.liferay.portal.service.ResourcePermissionLocalServiceUtil, \
com.liferay.portal.service.ResourcePermissionService,\
com.liferay.portal.service.ResourcePermissionLocalServiceUtil,\
com.liferay.portal.service.ResourcePermissionServiceUtil,\
com.liferay.portal.service.RoleLocalService,\
com.liferay.portal.service.UserLocalService
security-manager-get-bean-property=\
com.liferay.portal.kernel.util.FileUtil,\
com.liferay.portal.kernel.util.GetterUtil,\
com.liferay.portal.kernel.util.ParamUtil,\
com.liferay.portal.util.PortalUtil,\
com.liferay.portal.kernel.util.PrefsPropsUtil,\
com.liferay.portal.kernel.util.PropsUtil, \
com.liferay.portlet.documentlibrary.util.RawMetadataProcessorUtil

All that is standing between Liferay and world domination is clear documentation and simplifying really painful bits like the PACL.

There are bugs currently in PACL. Try running against the 6.2 M5 release to see if the problems have been resolved and, if not, open a ticket in issues.liferay.com to make sure they get addressed before the next release.

The security generator stuff that is in 6.2 M5 will also help identify and report on all of the security pieces that you'll need to define in your liferay-plugin-package.properties file.

You'll find that it will generate something like:

as suggested, I downloaded 6.2M5 and got that going. I set security manager to generate and deployed. I copied the output into the property file and deployed with security manager enabled. It turns out that the generate tool does not include entries for:

security-manager-get-bean-property
security-manager-files-write

So it took a lot of trial-and-error to add those entries. I finally got the portlet working in 6.2, then deployed it to 6.1.20 -- and it does not work. Right now I'm stuck on the file permissions. I get errors when uploading a file as part of a POST:

10:58:13,292 WARN [http-bio-48080-exec-38][FileChecker:256] Attempted to write file /Users/trapp/liferay-portal-6.1.20-ee-ga2-se/tomcat-7.0.27/temp/upload_00000006.jpg
10:58:13,296 WARN [http-bio-48080-exec-38][FileChecker:256] Attempted to read file /Users/trapp/liferay-portal-6.1.20-ee-ga2-se/tomcat-7.0.27/temp/upload_00000005
10:58:13,299 WARN [http-bio-48080-exec-38][FileChecker:256] Attempted to read file /Users/trapp/liferay-portal-6.1.20-ee-ga2-se/tomcat-7.0.27/temp/upload_00000006.jpg

In 6.2, this was fixed by:
security-manager-files-write=../temp/*
security-manager-files-read=../temp/*

for an upload that is written to /Users/trapp/liferay-portal-6.2.0-ce-m5/tomcat-7.0.34/temp/upload_00000149.jpg

In 6.1, I tried many different values, including this without success:
security-manager-files-write=*
security-manager-files-read=*

I've now spent more time trying to figure out the PACL stuff than I spent developing the app. This is the most frustrating experience I've had with Liferay in 2 years. Who at Liferay can I send my app to, to get this damn thing working? You guys wrote PACL, should be 50x faster for you to fix it than me.

Rather than using "../temp/-", you should be using "${java.io.tempdir}/-" since temp can be relocated on target systems.

Liferay won't do code analysis to determine what PACL rules you need, as the developer you are responsible for those.

In my testing of the security generator stuff, I did see it rendering those pieces that yours seems to have missed. You'd need to have exercised all points of your code to ensure that all of the rules would be generated/reported.

This is what the tool generated:
security-manager-files-read=\
/Users/trapp/liferay-portal-6.2.0-ce-m5/tomcat-7.0.34/temp/upload_00000149.jpg,\
/Users/trapp/liferay-portal-6.2.0-ce-m5/tomcat-7.0.34/temp/upload_00000152.jpg

I tried this but got the same errors as in my last post:
security-manager-files-write=${java.io.tempdir}/-
security-manager-files-read=${java.io.tempdir}/-

So how to fix this?


Okay, please give me clear documentation. The 6.1 documentation on PACL is quite insufficient. You guys must have internal documentation on this that is actually useful, right? Or lots of examples? Or maybe you can just provide me a liferay-plugin-package.properties file that will allow any actions on 6.1. Something, anything, please.


Done. I exercised every code path, then copied the contents of zsign-user-config-portlet.pacl-policy into my portlets liferay-plugin-package.properties. But it did not include these properties:
security-manager-get-bean-property
security-manager-files-write

Sorry, my bad, it's ${java.io.tmpdir}, not "tempdir"...

And, for the record, you say "you guys" and I think you mean me, but I am not a Liferay employee, just an avid poster

I think you're missing the point maybe about PACL. When an app is in the marketplace, other Liferay admins may choose to download and use the app. But they will want to know what resources the app uses so they can make an informed decision about whether to install it or not. It will also help to ensure that everything the app wants to do is accounted for, so if the app tries to delete all user accounts but that was not reported in the PACL rules it can be prevented from causing any harm.

Creating a set of PACL rules that basically gives any access would work against these two ideas. Even though your app is not malignant, having such a rule would allow a rogue developer to create a malignant app and cause all kinds of harm and would hurt the reputation of the marketplace.

If the generator for 6.2 M5 did not create the necessary rules for write and bean access, I'd suggest opening a jira ticket to report the issue. 6.2 M5 is on the path towards being the 6.2 CE release target, and the PACL work being done there is also going to be backported to the next 6.1 CE release. Reporting the issues will be important so they can get them fixed so your app will eventually work as advertised in the marketplace.

And I'm totally onboard w/ your complaint about the PACL docs... I could only figure out some of my rule syntax by using the generator... To me that's a crutch for missing documentation; I should be able to read the doco and create all of my necessary rules and not have to go to a generator to get the syntax for me...

Thanks for the reply David. I appreciate you taking the time to help. I wish Liferay's engineers would respond and address my remaining questions/concerns. Number 1 - update the PACL docs in the 6.1 Dev Guide so it is clear what to do.


Agreed, but I could then pare down the access to what is truly required. Liferay released the marketplace before PACL was fully baked, causing unnecessary grief for app developers -- the least they can do is come up with a workaround pronto (I guess they are doing that), and in the meantime directly help individuals who are blocked.


I couldn't agree more. Anyone at Liferay listening? David is a true Liferay expert, if he had trouble with the documentation then it clearly needs improvement.


that worked, thanks. I should have noticed the typo.

To reduce the amount of manual testing required, I created a Selenium WebDriver test for my portlet, so I can quickly test PACL changes. To anyone wrestling with PACL problems, I strongly recommend creating a test for your portlet using your an automated web test tool. Selenium IDE is better if you're an automated testing noob.

I opened a bug.

Hey Tim, yes, we are listening and I'm really sorry you've had to go through the PACL gauntlet to get your app working. We know it was premature and is painful (see my recent blog post), and are working as quickly as possible to update PACL (for both 6.1 and the upcoming 6.2, both of which will have the PACL generator you've been using from M5). You can also check out the updated documentation that is in place and will become "official" once one or both of the aforementioned releases are actually released (keep an eye on the Release Dashboard, Community homepage, or the Community blogs and you'll be sure to know exactly when this happens). Please see if the updated documentation is enough, and if not, file bugs and we'll get them updated asap.

Can you refer me to the bug you opened? I just want to make sure it's addressed if at all possible (I looked but did not see anything obvious, perhaps it wasn't an LPS JIRA bug?). And again, sorry for the difficulties. It is one of the things we've learned a lot from, and hopefully once we're over this "hump" it will be smooth sailing. Constructive criticism and feedback like yours is really really helpful, because we clearly can't know all of the scenarios for which apps are written. The good news is that your app, once in, will likely become part of the test bed for future releases - if a proposed release breaks a bunch of well-written apps, then the release will be held up and the reasons investigated.

The policy generator is a "semi automatic" tool. It requires the developer to fully exercise their plugin while the generator is enabled. The developer should QA each and very operation the plugin provides so that the full policy is generated. This includes making sure that any secondary processes (such as threads, or message bus publishers/listeners, scheduled jobs, external incoming or outgoing API calls) are triggered.

Otherwise, the generated policy will only be a partial representation (which may result in anyone downloading your plugin from the marketplace and having their PACL security enabled to receive errors from undeclared operations, but at least those operations will fail).

Ahk.. sorry, I missed that you had done the run through.

One more thing I wanted to add.

security-manager-get-bean-property on 6.2m5+ (and in the upcoming ee-fixed-PACL) doesn't produce the same list as you would get in 6.1.*

The reason is that we solved the cascading permission checks problem, which means that, for example, just because you use PortalUtil doesn't mean you also need to have permission for all of it's dependencies (which you can never control, including when we change the internals). So the list will be significantly different after our fixes.

Thanks Ray. I don't have any more time this week to work on this, especially since there is no way to estimate the time required to complete the task. I'm travelling next week, so the earliest I'll be back to this task is 5/20.



Thanks for pointing that out. When will the new and improved PACL generator be available for 6.1 EE?

I can only tell you that we are working very hard to get it out ASAP.

Rest assured we understand the implications of it not being released yet.