You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Radu Cotescu <ra...@apache.org> on 2016/10/06 10:03:41 UTC
restricting access for the "everyone" principal
Hi,
In SLING-5848 [1] Oliver has raised the question about restricting access
for the "everyone" principal, since we've started introducing service users
with very limited access. Currently the "everyone" principal is granted
read access on "/" for backwards compatibility reasons. For more details
see [2] and [3].
Should we change this and only allow "jcr:read" on a new /content folder
for "everyone"?
Thanks,
Radu
[1] - https://issues.apache.org/jira/browse/SLING-5848
[2] -
https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/java/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManager.java#L191
[3] -
https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/java/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManagerConfiguration.java#L60
Re: restricting access for the "everyone" principal
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 06 October 2016 13:21:49 Radu Cotescu wrote:
> Why do we need to remove that statement? sling-scripting is the user that
> scripting modules should use for reading scripts. Since Sling's
> "executable" content is in the search paths (which for now are /libs and
> /apps), I think that by default the sling-scripting user should not be
> allowed to do more.
Removing "deny" is not a must, but we should keep it simple and we do not gain
much (nothing?) from a security point of view as "everyone" (else) can read
from /content (or / with current setup).
We can not enforce scripting bundles to use the service/system user and simply
by using an anonymous resource resolver allows reading from /content (/).
I'm not sure if "deny" on / is a performance penalty also, maybe someone with
more insights can comment on this.
Regards,
O.
> On Thu, 6 Oct 2016 at 13:50 Oliver Lietz <ap...@oliverlietz.de> wrote:
> > - it is best practice to avoid "deny", so it should be removed from sling-
> > scripting (which would allow sling-scripting to read from /content also)
Re: restricting access for the "everyone" principal
Posted by Radu Cotescu <ra...@apache.org>.
Why do we need to remove that statement? sling-scripting is the user that
scripting modules should use for reading scripts. Since Sling's
"executable" content is in the search paths (which for now are /libs and
/apps), I think that by default the sling-scripting user should not be
allowed to do more.
On Thu, 6 Oct 2016 at 13:50 Oliver Lietz <ap...@oliverlietz.de> wrote:
> - it is best practice to avoid "deny", so it should be removed from sling-
> scripting (which would allow sling-scripting to read from /content also)
>
>
Re: restricting access for the "everyone" principal
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 06 October 2016 10:03:41 Radu Cotescu wrote:
> Hi,
>
> In SLING-5848 [1] Oliver has raised the question about restricting access
> for the "everyone" principal, since we've started introducing service users
> with very limited access. Currently the "everyone" principal is granted
> read access on "/" for backwards compatibility reasons. For more details
> see [2] and [3].
>
> Should we change this and only allow "jcr:read" on a new /content folder
> for "everyone"?
Some additional points:
- we should move the configuration for "everyone" from Oak Server to repoinit
(it was never implemented completely in Oak Server, so removing and logging a
warning should be fine)
- besides tests which might be affected, there may be other clients which rely
on reading / (we have to find out)
- it is best practice to avoid "deny", so it should be removed from sling-
scripting (which would allow sling-scripting to read from /content also)
Regards,
O.
> Thanks,
> Radu
>
> [1] - https://issues.apache.org/jira/browse/SLING-5848
> [2] -
> https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/j
> ava/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManager.java#
> L191 [3] -
> https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/j
> ava/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManagerConfig
> uration.java#L60
Re: restricting access for the "everyone" principal
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 06 October 2016 13:38:28 Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
>
> > Hi,
> >
> > On Thu, Oct 6, 2016 at 12:03 PM, Radu Cotescu <ra...@apache.org> wrote:
> >> ...Should we change this and only allow "jcr:read" on a new /content
> >> folder
> >> for "everyone"?...
> >
> > That might break a number of integration tests, I guess a dry run is
> > needed before making a decision, to see how much work is needed to fix
> > them.
>
> And while I think this restriction makes sense it might also break
> samples which do not use /content.
> This can be fixed of course, but if me make this change we shouldn't
> forget to adjust those things
As it seems we agree on restricting access for everyone, I will change the
path from "/" to "/content" in OakSlingRepositoryManager in a first step and
await what breaks (SLING-6130).
Regards,
O.
> Carsten
Re: restricting access for the "everyone" principal
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote
> Hi,
>
> On Thu, Oct 6, 2016 at 12:03 PM, Radu Cotescu <ra...@apache.org> wrote:
>> ...Should we change this and only allow "jcr:read" on a new /content folder
>> for "everyone"?...
>
> That might break a number of integration tests, I guess a dry run is
> needed before making a decision, to see how much work is needed to fix
> them.
>
And while I think this restriction makes sense it might also break
samples which do not use /content.
This can be fixed of course, but if me make this change we shouldn't
forget to adjust those things
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: restricting access for the "everyone" principal
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Oct 6, 2016 at 12:03 PM, Radu Cotescu <ra...@apache.org> wrote:
> ...Should we change this and only allow "jcr:read" on a new /content folder
> for "everyone"?...
That might break a number of integration tests, I guess a dry run is
needed before making a decision, to see how much work is needed to fix
them.
-Bertrand