Yes, I think that covers it, with the addition that 1. should also cover
sling:resourceSuperType
And the solution should not have a negative impact on the runtime
performance of request executions.
Regards
Carsten
Am 15.10.2018 um 11:10 schrieb Radu Cotescu:
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
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
