I've tried to update the ACLs for /apps and /libs using
$ curl -FprincipalId=administrators -Fprivilege@jcr:all=granted
http://admin:admin@localhost:8080/libs.modifyAce.html
This works for apps, but not for libs ; the error message from the HTML page is
Status: 404
Message: Resource is not a JCR Node
Location: /libs
Parent Location: /
In the sling explorer I don't see any properties for those nodes so they are
probably not JCR nodes . I did not place any resources by myself under /libs
but this was created by some Sling bundles, for instance the Sling Explorer
<Sling-Bundle-Resources>
/libs/sling/explorer,
/libs/sling/servlet/default/explorer
</Sling-Bundle-Resources>
How can I make sure that ACLs are applied to the /libs folder as well?
Thanks,
Robert
> -----Original Message-----
> From: Robert Munteanu
> Sent: Tuesday, June 12, 2012 10:35 AM
> To: [email protected]
> Subject: RE: Securing scripts under {libs,apps}
>
> Hi Eric,
>
> (Thanks to Davide and David for their answers as well)
>
> > -----Original Message-----
> > From: Eric Norman [mailto:[email protected]]
> > Sent: Sunday, June 10, 2012 7:46 AM
> > To: [email protected]
> > Subject: Re: Securing scripts under {libs,apps}
> >
> > If I recall correctly, if all your scripts are published to the JCR
> > repository, then you can just configure the JCR ACL to deny read
> access
> > to
> > everyone. Sling uses a "script user" (admin by default) to read the
> > scripts, so the end user doesn't have to have rights to read those
> > script
> > resources to use them. On the other hand, if your scripts are
> provided
> > by
> > some non JCR resource provider then you would have more work to do to
> > block
> > read access to those files.
>
> I'll go down the route of denying access to everyone to/{libs,apps} and
> allowing only the administrators group to read those. I might tweak it
> more since - for instance - the sling explorer deploys static assets to
> /libs/sling/explorer.
>
> I'll also look into setting up some rules on the reverse proxy - which
> is already there.
>
> Thanks,
>
> Robert
>
> >
> > Regards,
> > Eric
> >
> > On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
> > <[email protected]>wrote:
> >
> > > Ideally all security should be handled via JCR ACLs. Reverse proxy
> > > rules/dispatcher should be used to harden those ACLs. Be careful
> > using
> > > ACLs - as they may impede script resolution - I believe
> > > getResourceSuperType() where the SuperType is not readable by the
> > user
> > > will throw an error (unless this has already been fixed).
> > >
> > > Sent from my iPad
> > >
> > > On Jun 8, 2012, at 10:19 AM, Davide <[email protected]> wrote:
> > >
> > > > On 08/06/2012 13:46, Robert Munteanu wrote:
> > > >> Hi,
> > > >>
> > > >> I've recently been made aware that all resources under /apps are
> > > readable by everyone. This includes JSP scripts and I presume
> bundles
> > > deployed under the install folder.
> > > >>
> > > >> What is the recommended way of securing access to such
> resources?
> > > >
> > > > hi Robert,
> > > >
> > > > normally I work with CQ and in that case there's the Dispatcher
> > (apache
> > > > module) that takes care about it.
> > > >
> > > > Let's say that without knowing sling too much, if I'd have to do
> it
> > I
> > > > would manage it a 2 levels.
> > > >
> > > > First one with ACL in jackrabbit. Giving the read access only
> > behind
> > > > authentication.
> > > >
> > > > Second using the apache rewrite rules a would rewrite all /apps
> and
> > > > /libs to a 404.
> > > >
> > > > HTH
> > > > Davide
> > > >
> > >
