exist-development — eXist Developer's List

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Joe W. <jo...@gm...>]

Hi Adam,

> I don't think changing the security concerns here is a good idea. Rather I think the issue lies elsewhere, let me think about this...

Right, I see your point.  You're saying that the issue here could be seen as:

Giving guest users access to eXide is unwise.  This issue isn't
specific to eXide; it applies equally to letting users execute any
code which could run doc() or util:binary-doc() on a w+r resource.

You're saying that we need to start realizing that permissions now
dictate whether the the *system* can read/write/execute resources on a
given user's behalf, not whether the *user* can read/write/execute
resources.  The system is now an explicit intermediary between the
user and resources.  The system is the user's agent in
reading/writing/executing resources.

Is this a correct way of articulating the new permissions framework?

Joe

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Dmitriy S. <sha...@gm...>]

Before your refactoring only 'x' required.

Code itself should be protected as much as possible. It possible to make it
readable by internal mechanism, because we do not sending the code outside,
but sending it for evaluation and only result of evaluation is send outside.

On Wed, Feb 8, 2012 at 7:39 PM, Adam Retter <ad...@ex...> wrote:

> Indeed, XQuery is an interpreted language so you need both r and x.
>
> --
Dmitriy Shabanov

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Adam R. <ad...@ex...>]

>
> > Yes, that is reason to keep it unreadable but executable.
>
> Another downside of forcing .xq files to be "readable" (not just
"executable") is that the source code of the xquery can be exposed to the
user.  For example, say you have an app at /db/demo, and you have a
controller.xql file to handle URL requests.  This controller.xql has to be
world +rx.  But by being readable, you can display the source by accessing:
http://localhost:8080/exist/eXide/index.html?open=/db/demo/controller.xql.
 I don't think we want source to be viewable like this.  Based on this,
could we consider removing the requirement that .xq files must be world +r
in order to be browser-executable?
>

I don't think changing the security concerns here is a good idea. Rather I
think the issue lies elsewhere, let me think about this...

> Also, Dmitriy - you asked for a trace.  I wasn't sure which part of my
report you wanted a trace for?
>
> But I did just notice a bug - I'm just not sure if this is an app level
or system level issue.  The demo app (in svn, /exist/apps/demo > ant
build.xml > build/demo.xar) , the JSON demo at
http://localhost:8080/exist/apps/demo/examples/special/json.xql returns
this error to the browser:
>
>  <exception>
>    <path>/db/demo/examples/special/json.xql</path>
>    <message>
>        Could not locate collection: /db/system/security [at line 14,
column 22] In function: local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql] local:collections(xs:string*,
xs:string*) [18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
>    </message>
>  </exception>
>
> I think this is triggered by a call
to xmldb:get-child-collections('/db/system/security') on line 14 column 22
of the json.xql.  eXide's collection browser
(eXide/modules/collections.xql) prevents this error by adding this
conditional:
>
>   if (sm:has-access(xs:anyURI($root), "x")) then
>         let $children := xmldb:get-child-collections($root)
>
> Is this the suggested best practice -- checking for sm:has-access before
trying to use xmldb:get-*?
>
> Here is the error in exist.log:
>
> 2012-02-08 07:11:42,389 [eXistThread-39] DEBUG (RESTServer.java
[doGet]:487) - Could not locate collection: /db/system/security [at line
14, column 22]
> In function:
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
> org.exist.xquery.XPathException: Could not locate collection:
/db/system/security [at line 14, column 22]
> In function:
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
> at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.eval(XMLDBAbstractCollectionManipulator.java:160)
> at org.exist.xquery.BasicFunction.eval(BasicFunction.java:68)
> at
org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:55)
> at org.exist.xquery.LetExpr.eval(LetExpr.java:155)
> at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
> at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at
org.exist.xquery.FunctionCall$DeferredFunctionCallImpl.execute(FunctionCall.java:362)
> at
org.exist.xquery.DeferredFunctionCall.realize(DeferredFunctionCall.java:52)
> at
org.exist.xquery.DeferredFunctionCall.iterate(DeferredFunctionCall.java:208)
> at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:80)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
> at org.exist.xquery.ForExpr.eval(ForExpr.java:320)
> at org.exist.xquery.LetExpr.eval(LetExpr.java:208)
> at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
> at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at
org.exist.xquery.FunctionCall$DeferredFunctionCallImpl.execute(FunctionCall.java:362)
> at
org.exist.xquery.DeferredFunctionCall.realize(DeferredFunctionCall.java:52)
> at
org.exist.xquery.DeferredFunctionCall.iterate(DeferredFunctionCall.java:208)
> at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:80)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
> at org.exist.xquery.ForExpr.eval(ForExpr.java:320)
> at org.exist.xquery.LetExpr.eval(LetExpr.java:208)
> at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
> at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
> at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
> at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
> at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:70)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
> at
org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
> at org.exist.xquery.LetExpr.eval(LetExpr.java:210)
> at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
> at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
> at org.exist.xquery.XQuery.execute(XQuery.java:246)
> at org.exist.xquery.XQuery.execute(XQuery.java:201)
> at org.exist.http.RESTServer.executeXQuery(RESTServer.java:1403)
> at org.exist.http.RESTServer.doGet(RESTServer.java:478)
> at org.exist.http.servlets.EXistServlet.doGet(EXistServlet.java:246)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
> at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:241)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:115)
> at org.exist.http.urlrewrite.Forward.doRewrite(Forward.java:47)
> at
org.exist.http.urlrewrite.XQueryURLRewrite.doRewrite(XQueryURLRewrite.java:552)
> at
org.exist.http.urlrewrite.XQueryURLRewrite.service(XQueryURLRewrite.java:336)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
> at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
> at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at
org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: org.xmldb.api.base.XMLDBException: Permission denied to open
collection: /db/system/security
> at org.exist.xmldb.LocalCollection.getCollection(LocalCollection.java:218)
> at org.exist.xmldb.LocalCollection.<init>(LocalCollection.java:147)
> at org.exist.xmldb.LocalCollection.<init>(LocalCollection.java:121)
> at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.createLocalCollection(XMLDBAbstractCollectionManipulator.java:77)
> at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.eval(XMLDBAbstractCollectionManipulator.java:128)
> ... 110 more
> Caused by: org.exist.security.PermissionDeniedException: Permission
denied to open collection: /db/system/security
> at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:896)
> at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:741)
> at org.exist.storage.NativeBroker.getCollection(NativeBroker.java:736)
> at org.exist.xmldb.LocalCollection.getCollection(LocalCollection.java:210)
> ... 114 more
>
>
>
------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Adam R. <ad...@ex...>]

I am firstly trying to adhere to the Unix permissions model and so r and x
are required to load and then execute xquery.
On Feb 8, 2012 12:06 PM, "Dmitriy Shabanov" <sha...@gm...> wrote:

> On Wed, Feb 8, 2012 at 5:02 PM, Hungerburg <pc...@my...> wrote:
>
>> Am 2012-02-08 03:45, schrieb Joe Wicentowski:
>> >
>> > In hindsight I realize I was reading your advice below too literally.
>> > It makes sense that to "execute" a .xq via web browser, we need to not
>> > only make it "executable" but also "readable".
>> >
>> > Apologies if this is covered in basic unix permissions model, and
>> > apologies for my ignorance!
>>
>> In the unix model, scripts that are to be executed by an interpreter,
>> have to be both readable and executable by the user, while binaries,
>> that can be executed by the kernel directly only require execute
>> permission by the user. This difference does not make much sense in
>> eXist, does it?
>>
>> Requiring only exec permission for xquery procedures would allow to eg.
>> hardcode passwords in a script or use of some logic, that the executing
>> user must not learn. And after all, they are binaries in eXists native
>> object format, aren't they?
>>
>
> Yes, that is reason to keep it unreadable but executable.
>
> --
> Dmitriy Shabanov
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Adam R. <ad...@ex...>]

Indeed, XQuery is an interpreted language so you need both r and x.
On Feb 8, 2012 12:03 PM, "Hungerburg" <pc...@my...> wrote:

> Am 2012-02-08 03:45, schrieb Joe Wicentowski:
> >
> > In hindsight I realize I was reading your advice below too literally.
> > It makes sense that to "execute" a .xq via web browser, we need to not
> > only make it "executable" but also "readable".
> >
> > Apologies if this is covered in basic unix permissions model, and
> > apologies for my ignorance!
>
> In the unix model, scripts that are to be executed by an interpreter,
> have to be both readable and executable by the user, while binaries,
> that can be executed by the kernel directly only require execute
> permission by the user. This difference does not make much sense in
> eXist, does it?
>
> Requiring only exec permission for xquery procedures would allow to eg.
> hardcode passwords in a script or use of some logic, that the executing
> user must not learn. And after all, they are binaries in eXists native
> object format, aren't they?
>
> --
> peter
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Adam R. <ad...@ex...>]

Yes Joe you will need both r and x flags. r so the xquery processor can
read the file and x so that exist can execute it.
On Feb 8, 2012 2:45 AM, "Joe Wicentowski" <jo...@gm...> wrote:

> Hi Adam,
>
> In adapting my applications to the new security architecture, I wanted
> to report my experience and a problem I had.
>
> The immediate problem was that my .xq files, called via the browser,
> were not executing for guest users, even though I thought I understood
> your advice below and set the .xq file's permissions for world to --x.
>  The error as reported in the browser said, "Not Allowed To Read
> Collection".  I was a bit confused by this since the parent
> collection's permissions allowed reads.  No other information appeared
> in exist.log or any other logs, so my troubleshooting led me to
> examine permissions on an expath repo package (demo.xar) I installed
> via the admin page.  I saw its permissions on .xq files for world was
> r-x.
>
> In hindsight I realize I was reading your advice below too literally.
> It makes sense that to "execute" a .xq via web browser, we need to not
> only make it "executable" but also "readable".
>
> The new documentation at http://localhost:8080/exist/security.xml is
> very full, but I didn't see anything in the tables in the "Operational
> Permissions" section to the effect that "r-x" is required to "execute
> a .xq file in the browser".  "Execute a .xq" probably isn't the right
> terminology ("view" a .xq?  "call" a .xq?), but I hope it's clear.
>
> Apologies if this is covered in basic unix permissions model, and
> apologies for my ignorance!
>
> Cheers,
> Joe
>
>
> > 3) The 'u' update flag has been removed. Update really always meant
> > the same as Write anyway, so the Write flag covers all writes to
> > Resources now. The execute 'x' flag replaces that. Execute controls
> > the ability to a) Enter a Collection (just like a folder in Unix) and
> > b) to execute an XQuery script (just like shell scripts and bin's in
> > Unix).
> >
> > 4) Default permissions now follow the Unix model of 755 for
> > Collections i.e. rwxr-xr-x (including /db) and 644 for Resources i.e.
> > rw-r--r--
> > There is the facility in place for a umask, I will begin to expose
> > that along with setUID and setGID options in the near future.
> > NOTE - this means that XQuery scripts are no longer executable by
> > default (from a security perspective, thats important!). You will need
> > to set the 'x' flag on your XQuery scripts appropriately, so you can
> > now control execution by Owner/Group/World/ACL.
>

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Adam R. <ad...@ex...>]

This is NOT a bug. It is intended behaviour.
On Feb 8, 2012 4:40 AM, "Dmitriy Shabanov" <sha...@gm...> wrote:

> On Wed, Feb 8, 2012 at 7:45 AM, Joe Wicentowski <jo...@gm...> wrote:
>
>> In adapting my applications to the new security architecture, I wanted
>> to report my experience and a problem I had.
>>
>> The immediate problem was that my .xq files, called via the browser,
>> were not executing for guest users, even though I thought I understood
>> your advice below and set the .xq file's permissions for world to --x.
>>  The error as reported in the browser said, "Not Allowed To Read
>> Collection".  I was a bit confused by this since the parent
>> collection's permissions allowed reads.  No other information appeared
>> in exist.log or any other logs, so my troubleshooting led me to
>> examine permissions on an expath repo package (demo.xar) I installed
>> via the admin page.  I saw its permissions on .xq files for world was
>> r-x.
>>
>> In hindsight I realize I was reading your advice below too literally.
>> It makes sense that to "execute" a .xq via web browser, we need to not
>> only make it "executable" but also "readable".
>>
>> The new documentation at http://localhost:8080/exist/security.xml is
>> very full, but I didn't see anything in the tables in the "Operational
>> Permissions" section to the effect that "r-x" is required to "execute
>> a .xq file in the browser".  "Execute a .xq" probably isn't the right
>> terminology ("view" a .xq?  "call" a .xq?), but I hope it's clear.
>>
>
> This is a bug, IMHO. Can you send trace?
>
> --
> Dmitriy Shabanov
>

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Dmitriy S. <sha...@gm...>]

On Wed, Feb 8, 2012 at 5:33 PM, Joe Wicentowski <jo...@gm...> wrote:

>
> But I did just notice a bug - I'm just not sure if this is an app level or
> system level issue.  The demo app (in svn, /exist/apps/demo > ant build.xml
> > build/demo.xar) , the JSON demo at
> http://localhost:8080/exist/apps/demo/examples/special/json.xql returns
> this error to the browser:
>
>  <exception>
>    <path>/db/demo/examples/special/json.xql</path>
>    <message>
>        Could not locate collection: /db/system/security [at line 14,
> column 22] In function: local:sub-collections(xs:string*)
> [33:9:/db/demo/examples/special/json.xql] local:collections(xs:string*,
> xs:string*) [18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
> [18:19:/db/demo/examples/special/json.xql]
> local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
> local:collections(xs:string*, xs:string*)
> [40:6:/db/demo/examples/special/json.xql]
>    </message>
>  </exception>
>
> I think this is triggered by a call to *xmldb:get-child-collections*(*
> '/db/system/security'*) on line 14 column 22 of the json.xql.  eXide's
> collection browser (eXide/modules/collections.xql) prevents this error by
> adding this conditional:
>
> *  if* (*sm:has-access*(*xs:anyURI*(*$root*), "x")) *then*
>         *let **$children* := *xmldb:get-child-collections*(*$root*)
> Is this the suggested best practice -- checking for sm:has-access before
> trying to use xmldb:get-*?
>

Yes, if you do want to avoid exception to be send out you should check
permissions first or use try-catch.

-- 
Dmitriy Shabanov

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Joe W. <jo...@gm...>]

Hi all,

> Yes, that is reason to keep it unreadable but executable.

Another downside of forcing .xq files to be "readable" (not just
"executable") is that the source code of the xquery can be exposed to the
user.  For example, say you have an app at /db/demo, and you have a
controller.xql file to handle URL requests.  This controller.xql has to be
world +rx.  But by being readable, you can display the source by accessing:
http://localhost:8080/exist/eXide/index.html?open=/db/demo/controller.xql.
 I don't think we want source to be viewable like this.  Based on this,
could we consider removing the requirement that .xq files must be world +r
in order to be browser-executable?

Also, Dmitriy - you asked for a trace.  I wasn't sure which part of my
report you wanted a trace for?

But I did just notice a bug - I'm just not sure if this is an app level or
system level issue.  The demo app (in svn, /exist/apps/demo > ant build.xml
> build/demo.xar) , the JSON demo at
http://localhost:8080/exist/apps/demo/examples/special/json.xql returns
this error to the browser:

 <exception>
   <path>/db/demo/examples/special/json.xql</path>
   <message>
       Could not locate collection: /db/system/security [at line 14, column
22] In function: local:sub-collections(xs:string*)
[33:9:/db/demo/examples/special/json.xql] local:collections(xs:string*,
xs:string*) [18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
   </message>
 </exception>

I think this is triggered by a call to *xmldb:get-child-collections*(*
'/db/system/security'*) on line 14 column 22 of the json.xql.  eXide's
collection browser (eXide/modules/collections.xql) prevents this error by
adding this conditional:

*  if* (*sm:has-access*(*xs:anyURI*(*$root*), "x")) *then*
        *let **$children* := *xmldb:get-child-collections*(*$root*)
Is this the suggested best practice -- checking for sm:has-access before
trying to use xmldb:get-*?

Here is the error in exist.log:

2012-02-08 07:11:42,389 [eXistThread-39] DEBUG (RESTServer.java
[doGet]:487) - Could not locate collection: /db/system/security [at line
14, column 22]
In function:
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
 local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
 local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
org.exist.xquery.XPathException: Could not locate collection:
/db/system/security [at line 14, column 22]
In function:
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
 local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
 local:collections(xs:string*, xs:string*)
[18:19:/db/demo/examples/special/json.xql]
local:sub-collections(xs:string*) [33:9:/db/demo/examples/special/json.xql]
 local:collections(xs:string*, xs:string*)
[40:6:/db/demo/examples/special/json.xql]
at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.eval(XMLDBAbstractCollectionManipulator.java:160)
 at org.exist.xquery.BasicFunction.eval(BasicFunction.java:68)
at org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:55)
 at org.exist.xquery.LetExpr.eval(LetExpr.java:155)
at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
 at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
 at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
 at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
at
org.exist.xquery.FunctionCall$DeferredFunctionCallImpl.execute(FunctionCall.java:362)
 at
org.exist.xquery.DeferredFunctionCall.realize(DeferredFunctionCall.java:52)
at
org.exist.xquery.DeferredFunctionCall.iterate(DeferredFunctionCall.java:208)
 at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:80)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
 at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
 at org.exist.xquery.ForExpr.eval(ForExpr.java:320)
at org.exist.xquery.LetExpr.eval(LetExpr.java:208)
 at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
 at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
 at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
 at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
 at
org.exist.xquery.FunctionCall$DeferredFunctionCallImpl.execute(FunctionCall.java:362)
at
org.exist.xquery.DeferredFunctionCall.realize(DeferredFunctionCall.java:52)
 at
org.exist.xquery.DeferredFunctionCall.iterate(DeferredFunctionCall.java:208)
at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:80)
 at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
 at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
 at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
at org.exist.xquery.ForExpr.eval(ForExpr.java:320)
 at org.exist.xquery.LetExpr.eval(LetExpr.java:208)
at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
 at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
 at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
at org.exist.xquery.SequenceConstructor.eval(SequenceConstructor.java:83)
 at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:139)
at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:280)
 at org.exist.xquery.FunctionCall.eval(FunctionCall.java:206)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:70)
 at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
 at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:279)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
 at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
at org.exist.xquery.LetExpr.eval(LetExpr.java:210)
 at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.PathExpr.eval(PathExpr.java:276)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
 at org.exist.xquery.XQuery.execute(XQuery.java:246)
at org.exist.xquery.XQuery.execute(XQuery.java:201)
 at org.exist.http.RESTServer.executeXQuery(RESTServer.java:1403)
at org.exist.http.RESTServer.doGet(RESTServer.java:478)
 at org.exist.http.servlets.EXistServlet.doGet(EXistServlet.java:246)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
 at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
 at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
 at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
 at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
 at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:241)
 at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:115)
at org.exist.http.urlrewrite.Forward.doRewrite(Forward.java:47)
 at
org.exist.http.urlrewrite.XQueryURLRewrite.doRewrite(XQueryURLRewrite.java:552)
at
org.exist.http.urlrewrite.XQueryURLRewrite.service(XQueryURLRewrite.java:336)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
 at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
 at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
 at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
 at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
 at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
 at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
 at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
 at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
 at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
 at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.xmldb.api.base.XMLDBException: Permission denied to open
collection: /db/system/security
at org.exist.xmldb.LocalCollection.getCollection(LocalCollection.java:218)
 at org.exist.xmldb.LocalCollection.<init>(LocalCollection.java:147)
at org.exist.xmldb.LocalCollection.<init>(LocalCollection.java:121)
 at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.createLocalCollection(XMLDBAbstractCollectionManipulator.java:77)
at
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator.eval(XMLDBAbstractCollectionManipulator.java:128)
 ... 110 more
Caused by: org.exist.security.PermissionDeniedException: Permission denied
to open collection: /db/system/security
at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:896)
 at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:741)
at org.exist.storage.NativeBroker.getCollection(NativeBroker.java:736)
 at org.exist.xmldb.LocalCollection.getCollection(LocalCollection.java:210)
... 114 more

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Dmitriy S. <sha...@gm...>]

On Wed, Feb 8, 2012 at 5:02 PM, Hungerburg <pc...@my...> wrote:

> Am 2012-02-08 03:45, schrieb Joe Wicentowski:
> >
> > In hindsight I realize I was reading your advice below too literally.
> > It makes sense that to "execute" a .xq via web browser, we need to not
> > only make it "executable" but also "readable".
> >
> > Apologies if this is covered in basic unix permissions model, and
> > apologies for my ignorance!
>
> In the unix model, scripts that are to be executed by an interpreter,
> have to be both readable and executable by the user, while binaries,
> that can be executed by the kernel directly only require execute
> permission by the user. This difference does not make much sense in
> eXist, does it?
>
> Requiring only exec permission for xquery procedures would allow to eg.
> hardcode passwords in a script or use of some logic, that the executing
> user must not learn. And after all, they are binaries in eXists native
> object format, aren't they?
>

Yes, that is reason to keep it unreadable but executable.

-- 
Dmitriy Shabanov

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Hungerburg <pc...@my...>]

Am 2012-02-08 03:45, schrieb Joe Wicentowski:
>
> In hindsight I realize I was reading your advice below too literally.
> It makes sense that to "execute" a .xq via web browser, we need to not
> only make it "executable" but also "readable".
>
> Apologies if this is covered in basic unix permissions model, and
> apologies for my ignorance!

In the unix model, scripts that are to be executed by an interpreter, 
have to be both readable and executable by the user, while binaries, 
that can be executed by the kernel directly only require execute 
permission by the user. This difference does not make much sense in 
eXist, does it?

Requiring only exec permission for xquery procedures would allow to eg. 
hardcode passwords in a script or use of some logic, that the executing 
user must not learn. And after all, they are binaries in eXists native 
object format, aren't they?

-- 
peter

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Dmitriy S. <sha...@gm...>]

On Wed, Feb 8, 2012 at 7:45 AM, Joe Wicentowski <jo...@gm...> wrote:

> In adapting my applications to the new security architecture, I wanted
> to report my experience and a problem I had.
>
> The immediate problem was that my .xq files, called via the browser,
> were not executing for guest users, even though I thought I understood
> your advice below and set the .xq file's permissions for world to --x.
>  The error as reported in the browser said, "Not Allowed To Read
> Collection".  I was a bit confused by this since the parent
> collection's permissions allowed reads.  No other information appeared
> in exist.log or any other logs, so my troubleshooting led me to
> examine permissions on an expath repo package (demo.xar) I installed
> via the admin page.  I saw its permissions on .xq files for world was
> r-x.
>
> In hindsight I realize I was reading your advice below too literally.
> It makes sense that to "execute" a .xq via web browser, we need to not
> only make it "executable" but also "readable".
>
> The new documentation at http://localhost:8080/exist/security.xml is
> very full, but I didn't see anything in the tables in the "Operational
> Permissions" section to the effect that "r-x" is required to "execute
> a .xq file in the browser".  "Execute a .xq" probably isn't the right
> terminology ("view" a .xq?  "call" a .xq?), but I hope it's clear.
>

This is a bug, IMHO. Can you send trace?

-- 
Dmitriy Shabanov

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Joe W. <jo...@gm...>]

Hi Adam,

In adapting my applications to the new security architecture, I wanted
to report my experience and a problem I had.

The immediate problem was that my .xq files, called via the browser,
were not executing for guest users, even though I thought I understood
your advice below and set the .xq file's permissions for world to --x.
 The error as reported in the browser said, "Not Allowed To Read
Collection".  I was a bit confused by this since the parent
collection's permissions allowed reads.  No other information appeared
in exist.log or any other logs, so my troubleshooting led me to
examine permissions on an expath repo package (demo.xar) I installed
via the admin page.  I saw its permissions on .xq files for world was
r-x.

In hindsight I realize I was reading your advice below too literally.
It makes sense that to "execute" a .xq via web browser, we need to not
only make it "executable" but also "readable".

The new documentation at http://localhost:8080/exist/security.xml is
very full, but I didn't see anything in the tables in the "Operational
Permissions" section to the effect that "r-x" is required to "execute
a .xq file in the browser".  "Execute a .xq" probably isn't the right
terminology ("view" a .xq?  "call" a .xq?), but I hope it's clear.

Apologies if this is covered in basic unix permissions model, and
apologies for my ignorance!

Cheers,
Joe


> 3) The 'u' update flag has been removed. Update really always meant
> the same as Write anyway, so the Write flag covers all writes to
> Resources now. The execute 'x' flag replaces that. Execute controls
> the ability to a) Enter a Collection (just like a folder in Unix) and
> b) to execute an XQuery script (just like shell scripts and bin's in
> Unix).
>
> 4) Default permissions now follow the Unix model of 755 for
> Collections i.e. rwxr-xr-x (including /db) and 644 for Resources i.e.
> rw-r--r--
> There is the facility in place for a umask, I will begin to expose
> that along with setUID and setGID options in the near future.
> NOTE - this means that XQuery scripts are no longer executable by
> default (from a security perspective, thats important!). You will need
> to set the 'x' flag on your XQuery scripts appropriately, so you can
> now control execution by Owner/Group/World/ACL.

Re: [Exist-development] Security

[Patrick B. <pat...@jo...>]

Ok, that's what I had thought originally. Great!

On Tue, Feb 7, 2012 at 12:40 PM, Adam Retter <ad...@ex...> wrote:
> No. Execution  of XQuery scripts is controlled by the 'x' flag in the
> permissions mask of each .xql file.
>
> On 7 February 2012 13:27, Patrick Bosek <pat...@jo...> wrote:
>> I feel like I may have missed part of this conversation, so I
>> apologize in advance if my question is irrelevant.
>>
>> Does the proposal to move apps to /db/apps mean that only .xql under
>> /db/apps would be able to be executed?
>>
>>
>> Cheers,
>>
>> Patrick
>>
>> On Tue, Feb 7, 2012 at 5:10 AM, Wolfgang Meier <wol...@ex...> wrote:
>>>> I agree to expose the whole db under /apps is not a very good idea. When
>>>> give access to the db we should limit it to a collection that is dedicated
>>>> for this purpose. Something like /db/apps.
>>>
>>> Indeed we already discussed this here before and the decision was to
>>> use /db/apps as the root for all apps. I just had no time to make the
>>> required changes so far.
>>>
>>> Wolfgang
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Exist-development mailing list
>>> Exi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/exist-development
>>
>>
>>
>> --
>> Patrick Bosek
>> Jorsek Software
>> Cell (585) 820 9634
>> Office (877) 492 2960
>> Jorsek.com
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb



-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com

Re: [Exist-development] Security

[Adam R. <ad...@ex...>]

No. Execution  of XQuery scripts is controlled by the 'x' flag in the
permissions mask of each .xql file.

On 7 February 2012 13:27, Patrick Bosek <pat...@jo...> wrote:
> I feel like I may have missed part of this conversation, so I
> apologize in advance if my question is irrelevant.
>
> Does the proposal to move apps to /db/apps mean that only .xql under
> /db/apps would be able to be executed?
>
>
> Cheers,
>
> Patrick
>
> On Tue, Feb 7, 2012 at 5:10 AM, Wolfgang Meier <wol...@ex...> wrote:
>>> I agree to expose the whole db under /apps is not a very good idea. When
>>> give access to the db we should limit it to a collection that is dedicated
>>> for this purpose. Something like /db/apps.
>>
>> Indeed we already discussed this here before and the decision was to
>> use /db/apps as the root for all apps. I just had no time to make the
>> required changes so far.
>>
>> Wolfgang
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (877) 492 2960
> Jorsek.com
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Security

[Dmitriy S. <sha...@gm...>]

On Tue, Feb 7, 2012 at 6:27 PM, Patrick Bosek <pat...@jo...>wrote:

> I feel like I may have missed part of this conversation, so I
> apologize in advance if my question is irrelevant.
>
> Does the proposal to move apps to /db/apps mean that only .xql under
> /db/apps would be able to be executed?
>

No, that is the question of default mapping, but this mapping can be
changed any time.

-- 
Dmitriy Shabanov

Re: [Exist-development] Security

[Patrick B. <pat...@jo...>]

I feel like I may have missed part of this conversation, so I
apologize in advance if my question is irrelevant.

Does the proposal to move apps to /db/apps mean that only .xql under
/db/apps would be able to be executed?


Cheers,

Patrick

On Tue, Feb 7, 2012 at 5:10 AM, Wolfgang Meier <wol...@ex...> wrote:
>> I agree to expose the whole db under /apps is not a very good idea. When
>> give access to the db we should limit it to a collection that is dedicated
>> for this purpose. Something like /db/apps.
>
> Indeed we already discussed this here before and the decision was to
> use /db/apps as the root for all apps. I just had no time to make the
> required changes so far.
>
> Wolfgang
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development



-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com

Re: [Exist-development] Security

[Wolfgang M. <wol...@ex...>]

> I agree to expose the whole db under /apps is not a very good idea. When
> give access to the db we should limit it to a collection that is dedicated
> for this purpose. Something like /db/apps.

Indeed we already discussed this here before and the decision was to
use /db/apps as the root for all apps. I just had no time to make the
required changes so far.

Wolfgang

Re: [Exist-development] Security

[Hungerburg <pc...@my...>]

Am 2012-02-07 10:48, schrieb Thomas White:
>
> On 6 February 2012 23:14, Hungerburg <pc...@my...
> <mailto:pc...@my...>> wrote:
>
>     # Exposing all of db through the "apps" namespace in addition to the
>     "rest" namespace, from the "security is a process" standpoint, does not
>     look a good decision. MVC theory instead proposes, to store
>     (confidential) data outside of the web-root.
>
>
> I agree to expose the whole db under /apps is not a very good idea. When
> give access to the db we should limit it to a collection that is
> dedicated for this purpose. Something like /db/apps. This way there will
> be a clear separation between the data and the applications, nicely
> located in a single place. The application's code will access the rest
> of the db if and when needed in a controlled manner.

The security consideration is that, when data is not reachable, except 
through the controller, the controller is not responsible for hiding the 
data. So there is one less mistake, a developer can make, eg. forgetting 
to shadow some part of db (rest space being disabled). Developers still 
can make mistakes...

> So my proposition is to change the redirection /apps - > /db    to /apps
> -> /db/apps

Of course, this will make app development trickier. A simple app migth 
still be deployed by unzipping files below a single root in /apps. Where 
sensitive data is handled, the app would be dual rooted then though. The 
public part below /apps and the private part below /db/foo for example. 
Path constructions get more cumbersome, relocating apps will be more 
difficult too, etc. But for eg. medical records or other personal data, 
this is a must, isnt it?

-- 
peter

Re: [Exist-development] Security

[Thomas W. <tho...@gm...>]

On 6 February 2012 23:14, Hungerburg <pc...@my...> wrote:

> # Exposing all of db through the "apps" namespace in addition to the
> "rest" namespace, from the "security is a process" standpoint, does not
> look a good decision. MVC theory instead proposes, to store
> (confidential) data outside of the web-root.
>
>
I agree to expose the whole db under /apps is not a very good idea. When
give access to the db we should limit it to a collection that is dedicated
for this purpose. Something like /db/apps. This way there will be a clear
separation between the data and the applications, nicely located in a
single place. The application's code will access the rest of the db if and
when needed in a controlled manner.

So my proposition is to change the redirection /apps - > /db    to /apps ->
/db/apps

Thomas

Re: [Exist-development] Security

[Adam R. <ad...@ex...>]

> # Exposing all of db through the "apps" namespace in addition to the "rest"
> namespace, from the "security is a process" standpoint, does not look a good
> decision. MVC theory instead proposes, to store (confidential) data outside
> of the web-root.

Yes I agree the security concerns here are bad.

> # I have the gut feeling, that by requesting a restricted resource from
> "rest" space, thereby adding credentials via http-auth, that this creates a
> server side session, allowing me to browse "admin.xql" without being
> prompted for login. Rest is said to be stateless, though.

Yes that is the case.

> I hope, this sounds sufficiently sober to be considered.

I plan to launch Project Sleepy at Prague. This should solve both of
your above concerns I hope.

> Yours
>
> Peter
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Security

[Hungerburg <pc...@my...>]

Thank you Adam for taking the time to justify your decision. I 
understand that it is not easy on anybody, to feel prommpted to justify 
one’s efforts.

I cannot argue about the cost of 256 vs 160 bytes per digest or 
processing power/number of instructions per digestification (what a 
funny word, should it be digestion :). I consider the SHA reference 
implementation fairly good documented though, and I believe in that it 
has gotten quite a lot of scrutiny by the experts in the field, and so 
it seemed wrong to me, to describe it in such a way.

Just like you, I think security has to be accounted for with a straight 
face. Why not provide the same security as a bank does, if it is 
affordable? World famous Bruce Schneier does not get tired of saying, 
that security is a trade-off. So,

I wish you all a happy bargaining in Prague.

While I will enjoy my beer at home, may I suggest two more points to the 
security debate (in the interest of the eXist project, in my humble view):

# Exposing all of db through the "apps" namespace in addition to the 
"rest" namespace, from the "security is a process" standpoint, does not 
look a good decision. MVC theory instead proposes, to store 
(confidential) data outside of the web-root.

# I have the gut feeling, that by requesting a restricted resource from 
"rest" space, thereby adding credentials via http-auth, that this 
creates a server side session, allowing me to browse "admin.xql" without 
being prompted for login. Rest is said to be stateless, though.

I hope, this sounds sufficiently sober to be considered.

Yours

Peter

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

face2face discussion would be good, but….. we all must be willing to be open for reasonable arguments. So far……. hmmmm

--  
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624


On Monday, 6 February 2012 at 20:54 , Loren Cahlander wrote:

> Can we save this discussion for Friday in Prague? I think that this discussion would be best face-to-face (preferable with beer as the lubricant to the discussion).  

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Dannes W. <da...@ex...>]

for sure! thnx! 

-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624


On Monday, 6 February 2012 at 22:21 , Joe Wicentowski wrote:

> Absolutely! Thanks for all your hard work on this, Adam! 

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

Hi

On Monday, 6 February 2012 at 20:52 , Dmitriy Shabanov wrote:

> We have too big war on very small peace of code

right, somehow trying to discuss via mail does not work………




--  
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624