[ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549498#comment-15549498
 ] 

Oliver Lietz commented on SLING-5848:
-------------------------------------

[~radu.cotescu], see 
{{org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager}} and its 
configuration:
{noformat}
    private void setup(final SlingRepository repository) {
        final boolean anonymous_read_all = configuration.anonymous_read_all();
        if (anonymous_read_all) {
            log.warn("anonymous.read.all is true, granting anonymous user read 
access on /");
            Session session = null;
            try {
                // TODO do we need to go via PrivilegeManager for the names? 
See OAK-1016 example.
                session = repository.loginAdministrative(getDefaultWorkspace());
                final String[] privileges = new String[]{Privilege.JCR_READ};
                AccessControlUtils.addAccessControlEntry(
                    session,
                    "/",
                    EveryonePrincipal.getInstance(),
                    privileges,
                    true);
                session.save();
            } catch (RepositoryException re) {
                log.error("TODO: Failed setting up anonymous access", re);
            } finally {
                if (session != null) {
                    session.logout();
                }
            }
        } else {
            log.warn("TODO: should disable anonymous access when 
anonymous.read.all becomes false");
        }
    }
{noformat}

{noformat}
    @AttributeDefinition(
        name = "Allow anonymous reads",
        description = "If true, the anonymous user has read access to the whole 
repository (for backwards compatibility)"
    )
    boolean anonymous_read_all() default true;
{noformat}

I would really like to cut {{read}} access down for {{everyone}}, either 
completely or granting on {{/content}} only. But I'm not sure which users will 
be affected and why we have this backwards compatibility. [~cziegeler], 
[~bdelacretaz] any ideas?

> Define service user and ACLs for Scripting
> ------------------------------------------
>
>                 Key: SLING-5848
>                 URL: https://issues.apache.org/jira/browse/SLING-5848
>             Project: Sling
>          Issue Type: Task
>          Components: Launchpad, Scripting
>            Reporter: Oliver Lietz
>            Assignee: Oliver Lietz
>             Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to