My understanding of this thread is that it is about "controlling execution of servlets/scripts pertaining to individual resource-types".
Carsten's point that we may want more fine-grained control, i.e. differentiate between "view" and "execute" (which may often be GET and POST), sounds sensible. Therefore it makes sense to me to include this requirement in the discussion. So far I am not convinced that any new API is needed to achieve this. And am therefore opposed to any solution that proposes/requires a new API. I see two existing APIs, which could help: - ResourceAccessGate - which I feel that some in this discussion don't understand how it could relate to resource-types and so far I seem to have failed to explain it properly - ResourceDecorator - we could "decorate-away" resource types that a user is not allowed to see, or even substitute them to render an error message instead. Via resource.getResourceResolver().getUserID() we have access to the current user. For any of these mechanisms to work, the script-user may be a hindrance. But I believe it would be worthwhile exploring if we cannot change this in a way that allows the approach to work. Regards Julian On Sun, Oct 7, 2018 at 8:17 AM 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
