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 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
