> > 1. Users can freely define sling:resourceType properties
Is there some reason why this must be so? In JCR land, the jcr:nodeTypeManagement privilege must be granted for the user to have permission to add and remove mixin node types and change the primary node type of a node. I would expect that a similar elevated privilege could protect against unwanted modifications of the sling:resourceType values by the wrong users. For #2 and #3, perhaps what you are really describing is a mechanism for defining and checking what I would call "functional privileges"? In other words, not the same as permissions on the data, but permissions on the action. Would it be necessary to associate those "functional privileges" to a resource type? I can imagine you may want to define a "functional privilege" that could be checked by some servlet/filter/component/osgi_service/model/other that works for many different resource types or no specific resource type at all. For example, 1. Imagine a resource defined at "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" permissions determines if the user can perform the "usage_report" servlet action. 2. Then the "usage_report" servlet simply has to has to check if the "yourapp/usage_report" resource at #1 exists for the current user (or some higher level API that does the same) to know if the servlet should proceed or return an error code. 3. For scripts, perhaps a sling:functionalPrivilege property on the resource could define what is required and block the script processing generically when those conditions are not satisfied. That's my 2 cents.. Regards, -Eric On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu <r...@apache.org> wrote: > Hi, > > Since this thread exploded so quickly it’s going to be difficult to > respond to all of your questions / concerns individually. We eagerly > started discussing implementation details (of which I’m to blame too) and I > think we didn’t read between the lines of this thread or the previous [0] > to check what the perceived problems are. > > Both threads identified several issues: > 1. Users can freely define sling:resourceType properties > 2. Through 1, users can therefore trigger code execution which is not > always appropriate (depends on how Servlets / scripts are written and the > potential they have to DoS a system or to expose sensible information to > users which shouldn’t have the ability to perform those operations) > 3. For some operations (servlet execution, tasks, etc.) we might want to > provide a set of permissions to check beforehand in order to decide if a > user is allowed to perform said operation or not. > > In this thread I proposed an idea to fix issue no. 2 (which IMO is easier > to accomplish) - and by fix I mean provide a way to define who can execute > what - so that we don’t care about issue no. 1 any more. > > Let’s try to figure out if indeed these are some serious problems that > need to be addressed or not. We can discuss implementation details > afterwards. > > Cheers, > Radu > > >
