Hi Carsten, So then the requirements should be:
1. Protect the creation of the sling:resourceType property 2. Provide granular permissions for which resource type / selector & extension / HTTP method we allow the execution of a script / servlet and code to enforce them in either the servlet resolution phase or servlet execution 3. Make sure that restrictions can work within the resource type hierarchy Did I miss something? Thanks, Radu > On 7 Oct 2018, at 10:16, Carsten Ziegeler <cziege...@apache.org> wrote: > > I agree with Eric here, independent of the how we protect the execution, > we should also tackle the initial problem that everyone with write > access can set any resource type. It seems strange that we invite > everyone with weapons into our house and then try to prevent them from > using it. We should keep them out in the first place. > > I also think that a mechanism purely working resource types is not > exactly what we need. Think about you have a "view" and an "execute" > script for a resource type (potentially attached to selectors). Users > may be able to use the "view" script but "execute" is more protected. > > Then we have the resource type hierarchy, so if I'm able to set a > resource type I can also set a resource super type. We need to make sure > that this does not open something we wanted to close. I think the > current proposals cover this, but it should be verified. > > So all in all, I think this problem is more complex than just adding a > service with a single method and pretend that everything else are > implementation details. > > Regards > > Carsten > > > Eric Norman wrote >>> >>> 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 >>> >>> >>> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
