Hi Chetan

That's a completely different thing:
The developer of you code makes an (hopefully informed) decision to
use another super-privileged session to perform a given task.

While with your proposed change we just open the door and make it
work without enforcing an informed decision (instead just having a
note in the Javadoc (which probably gets ignored) given away the
ability to secure access to those binaries.

And just for the sake of correctness:

1. Neither JCR nor Jackrabbit nor Oak comes with a Repository.loginAsAdmin
   call. This has been discussed once in the past and we made a conscious
   decision not to do this for various reasons including security.

2. SlingRepository.loginAdministrative, which you are referring to has
been 
   a constant source of most severe vulnerabilities putting every customer
   of Sling-based applications at risk; despite the fact that the API
contract 
   (i.e. javadoc) was utterly clear about the risk and asked for using it
   responsively [1]. As you know the Apache Sling team ended up
deprecating 
   the method because it caused too many security issues!

Kind regards
Angela


[1] quote from javadoc of SlingRepository.loginAdministrative:

* <i>NOTE: This method is intended for use by infrastructure bundles to
* access the repository and provide general services. This method MUST not
* be used to handle client requests of whatever kinds. To handle client
* requests a regular authenticated session retrieved through
* {@link #login(javax.jcr.Credentials, String)} or
* {@link Session#impersonate(javax.jcr.Credentials)} must be used.</i></b>


On 05/05/16 13:50, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote:

>On Thu, May 5, 2016 at 5:07 PM, Francesco Mari <mari.france...@gmail.com>
>wrote:
>
>>
>> This is a totally different thing. The change to the node will be
>>committed
>> with the privileges of the session that retrieved the node. If the
>>session
>> doesn't have enough privileges to delete that node, the node will be
>> deleted, There is no escape from the security model.
>
>
>A "bad code" when passes a node backed via admin session can still do bad
>thing as admin session has all the privileges. In same way if a bad code
>is
>passed a file handle then it can cause issue. So I am still not sure on
>the
>attack vector which we are defending against.
>
>Chetan Mehrotra

Reply via email to