exist-development — eXist Developer's List

Re: [Exist-development] Confused about permissions and defaults for XQuery files

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

On Oct 18, 2011 9:34 AM, "Chris Tomlinson" <chr...@gm...>
wrote:
>
> Wolfgang,
>
> So "*w*" on a file, F will be sufficient to grant update and delete or
will delete require "*w*" on the collection containing F?
>

Yes you will need write on the parent collection to delete a file. This is
the Unix model. If its not implemented now, it will be when the changes are
finished.

> Is this change one that is pending for the 1.6 transition of trunk?
>
> Thank you,
> Chris
>
>
>
> On Oct 18, 2011, at 1:37 PM, Wolfgang Meier wrote:
>
>> > for xml resource it should be 'rwu', for binary & collections (or only
xquery scripts, not clear for me) 'rwx'
>>
>> No, I thought we would drop the update semantics altogether. "x" should
always mean "execute", no matter if eXist knows how to execute a particular
resource.
>>
>> Wolfgang
>
>
>
>
------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>

Re: [Exist-development] Confused about permissions and defaults for XQuery files

[Chris T. <chr...@gm...>]

Adam,

1) So if I understand correctly then there is no longer any default permissions feature any where, including in the collection.xconf files for various collections. Is this correct? It seems contrary to the portion of the thread with Dmitriy so you'll appreciate my confusion.

2) What is the security issue? Incorrect admin of the DB is always an opportunity for problems: performance, security and so on. It seems to me that removing the ability to provide a default set of permissions some how - on a collection or on a per user basis or whatever - is a significant reduction in functionality in order to keep some DB admins from shooting themselves in the foot so to speak. This means to me that eXist is now enforcing a particular policy rather than providing mechanism.

3) Setting permissions after upload is an additional step that is not supported by the admin.xq and that is poorly supported by the java admin GUI since for large collections (1000s of files) remotely one has to list the entire collection contents before being able to then use the GUI panel for permissions. The command line on a headless server works with less performance issue but doesn't seem to support any wildcarding or other method of selecting multiple files / collections for the chmod to affect.

Chris


On Oct 18, 2011, at 2:21 PM, Adam Retter wrote:

> 
> On Oct 18, 2011 6:16 AM, "Chris Tomlinson" <chr...@gm...> wrote:
> >
> > Hello,
> >
> > I'm looking into some issues surrounding permissions management in current trunk and am trying to make sure I understand what is intended and what is implemented in this area. I ran across this post of yours from 3 months ago and I wanted to know the status in this area is or whether it has been reconsidered.
> 
> No the plan is still in progress.
> 
> > In looking at org.exist.security.Permission.java it looks like it hasn't been worked on since 4 Aug and the "update" nomenclature is still in place and used in org.exist.security.AbstractUnixStylePermission.java which hasn't been worked on for even longer.
> >
> > Trunk certainly still interprets the "u" perm as indicating that the file is updatable or not (versus deletable "w") and throws an error in the event that a user attempts to update and that flag isn't set for the user, group or other as appropriate.
> >
> > Is this the behavior we can expect as trunk morphs into 1.6 or are there more changes on the way for org.exist.security?
> >
> 
> A few more changes to come. Other priorities got in the way. But its top of my list again.
> 
> > I also seem to not understand the semantics of the <db-connection/> <default-permissions collection="0774" resource="0774" /> in the conf.xml file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't seem to make any difference. For example, when I upload a file via the http://localhost:8080/exist/admin/admin.xql > Browse collections interface I get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have expected. The same is true when running java client from the command line.
> 
> Default permissions have been removed as a security concern.
> 
> > We have need of being able to upload files and the resulting permissions need to be "rwuruwr--" by default. How do we achieve this via the admin.xql or the command line client?
> 
> You can set perms after upload...
> 
> > Thanks,
> > Chris
> >
> >
> > On Jul 7, 2011, at 12:33 PM, Wolfgang Meier wrote:
> >
> > >> #1: Why does my controller.xql file need guest update permissions for
> > >> regular web browsing?
> > >
> > > For XQuery resources, the permission flags are now interpreted as rwx
> > > instead of the old rwu. We're in the process of changing this
> > > everywhere. The documentation is a bit behind.
> > >
> > > Wolfgang
> > >
> > > ------------------------------------------------------------------------------
> > > All of the data generated in your IT infrastructure is seriously valuable.
> > > Why? It contains a definitive record of application performance, security
> > > threats, fraudulent activity, and more. Splunk takes this data and makes
> > > sense of it. IT sense. And common sense.
> > > http://p.sf.net/sfu/splunk-d2d-c2
> > > _______________________________________________
> > > Exist-open mailing list
> > > Exi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/exist-open
> >
> >
> > ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct
> > _______________________________________________
> > Exist-development mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-development

Re: [Exist-development] Confused about permissions and defaults for XQuery files

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

On Oct 18, 2011 6:16 AM, "Chris Tomlinson" <chr...@gm...>
wrote:
>
> Hello,
>
> I'm looking into some issues surrounding permissions management in current
trunk and am trying to make sure I understand what is intended and what is
implemented in this area. I ran across this post of yours from 3 months ago
and I wanted to know the status in this area is or whether it has been
reconsidered.

No the plan is still in progress.

> In looking at org.exist.security.Permission.java it looks like it hasn't
been worked on since 4 Aug and the "update" nomenclature is still in place
and used in org.exist.security.AbstractUnixStylePermission.java which hasn't
been worked on for even longer.
>
> Trunk certainly still interprets the "u" perm as indicating that the file
is updatable or not (versus deletable "w") and throws an error in the event
that a user attempts to update and that flag isn't set for the user, group
or other as appropriate.
>
> Is this the behavior we can expect as trunk morphs into 1.6 or are there
more changes on the way for org.exist.security?
>

A few more changes to come. Other priorities got in the way. But its top of
my list again.

> I also seem to not understand the semantics of the <db-connection/>
<default-permissions collection="0774" resource="0774" /> in the conf.xml
file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't
seem to make any difference. For example, when I upload a file via the
http://localhost:8080/exist/admin/admin.xql > Browse collections interface I
get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have
expected. The same is true when running java client from the command line.

Default permissions have been removed as a security concern.

> We have need of being able to upload files and the resulting permissions
need to be "rwuruwr--" by default. How do we achieve this via the admin.xql
or the command line client?

You can set perms after upload...

> Thanks,
> Chris
>
>
> On Jul 7, 2011, at 12:33 PM, Wolfgang Meier wrote:
>
> >> #1: Why does my controller.xql file need guest update permissions for
> >> regular web browsing?
> >
> > For XQuery resources, the permission flags are now interpreted as rwx
> > instead of the old rwu. We're in the process of changing this
> > everywhere. The documentation is a bit behind.
> >
> > Wolfgang
> >
> >
------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously
valuable.
> > Why? It contains a definitive record of application performance,
security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Exist-open mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
>
------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development

Re: [Exist-development] Confused about permissions and defaults for XQuery files

[Chris T. <chr...@gm...>]

Wolfgang,

So "*w*" on a file, F will be sufficient to grant update and delete or will delete require "*w*" on the collection containing F?

Is this change one that is pending for the 1.6 transition of trunk?

Thank you,
Chris



On Oct 18, 2011, at 1:37 PM, Wolfgang Meier wrote:

> > for xml resource it should be 'rwu', for binary & collections (or only xquery scripts, not clear for me) 'rwx'
> 
> No, I thought we would drop the update semantics altogether. "x" should always mean "execute", no matter if eXist knows how to execute a particular resource.
> 
> Wolfgang

Re: [Exist-development] default perms in collection.xconf do not seem to work

[Chris T. <chr...@gm...>]

Yes I am uploading to /db/tbrc. That is to say I am uploading to a collection for which there is a collection.xconf containing the <default-permissions/>.

Here's a screen shot of the configuration:




Here's a screenshot of the collection.xconf:



Here's a screenshot of the resulting upload of TEST-01.xml:



Chris


On Oct 18, 2011, at 1:31 PM, Dmitriy Shabanov wrote:

> You uploading to " /db/tbrc" ? need to check... 
> 
> On Tue, Oct 18, 2011 at 12:25 PM, Chris Tomlinson <chr...@gm...> wrote:
> I'm confused. I uploaded the files into the top collection, /db/tbrc which is where the <default-permissions/> is placed in the collection.xconf file for the top collection /db/tbrc. Unless you're saying that I have to have a collection.xconf for /db itself which I don't think is what you're saying. Surely, I don't need to add <default-permissions/> to collections /db/tbrc/A and /db/tbrc/B and so on in order to control the default permissions for files uploaded into collection /db/tbrc??
> 
> 
> -- 
> Dmitriy Shabanov

Re: [Exist-development] Confused about permissions and defaults for XQuery files

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

> for xml resource it should be 'rwu', for binary & collections (or only
xquery scripts, not clear for me) 'rwx'

No, I thought we would drop the update semantics altogether. "x" should
always mean "execute", no matter if eXist knows how to execute a particular
resource.

Wolfgang

Re: [Exist-development] default perms in collection.xconf do not seem to work

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

You uploading to " */db/tbrc*" ? need to check...

On Tue, Oct 18, 2011 at 12:25 PM, Chris Tomlinson <
chr...@gm...> wrote:

> I'm confused. I uploaded the files into the top collection, */db/tbrc*which is where the
> *<default-permissions/>* is placed in the *collection.xconf* file for the
> top collection */db/tbrc*. Unless you're saying that I have to have a *
> collection.xconf* for* /db* itself which I don't think is what you're
> saying. Surely, I don't need to add *<default-permissions/>* to
> collections */db/tbrc/A* and */db/tbrc/B* and so on in order to control
> the default permissions for files uploaded into collection */db/tbrc*??
>


-- 
Dmitriy Shabanov

Re: [Exist-development] default perms in collection.xconf do not seem to work

[Chris T. <chr...@gm...>]

Dmitriy,

I'm confused. I uploaded the files into the top collection, /db/tbrc which is where the <default-permissions/> is placed in the collection.xconf file for the top collection /db/tbrc. Unless you're saying that I have to have a collection.xconf for /db itself which I don't think is what you're saying. Surely, I don't need to add <default-permissions/> to collections /db/tbrc/A and /db/tbrc/B and so on in order to control the default permissions for files uploaded into collection /db/tbrc??

Thanks,
Chris



On Oct 18, 2011, at 1:02 PM, Dmitriy Shabanov wrote:

> add default-permissions to each collection.xconf, not just top one.
> 
> I did write: it will look up to first configuration. But if that first configuration don't have default-permission, then it use internal-default one. That is current behavior.
> 
> On Tue, Oct 18, 2011 at 12:11 PM, Chris Tomlinson <chr...@gm...> wrote:
> Dmitriy,
> 
> The collections are structured as:
> 
> /db/tbrc
> /db/tbrc/A
> /db/tbrc/B
> 
> and I have collection.xconf files for /db/tbrc and /db/tbrc/A and /db/tbrc/B. There is no collection.xconf for /db
> 
> However, for the purposes of this test I only put the <default-permissions/> in the collection.xconf for /db/tbrc and then did the uploads into the collection /db/tbrc. I would assume the presence of collection.xconf files below /db/tbrc would have effect on the uploads into /db/tbrc.
> 
> I note that back on 4 Aug, Efraim Feinstein remarked:
> 
>> (3) The obvious way to do (2) is the default-permissions element in 
>> conf.xml. As far as I can tell, setting the resource parameter to 770 is 
>> doing nothing.
> 
> So apparently he was having difficulties in the same area. I saw no replies regarding his observation.
> 
> Chris
> 
> 
> 
> On Oct 18, 2011, at 12:47 PM, Dmitriy Shabanov wrote:
> 
>> is it only collection.xconf that you have?
>> 
>> On Tue, Oct 18, 2011 at 11:23 AM, Chris Tomlinson <chr...@gm...> wrote:
>> 
>> I added the defaults as you indicated to the collection.xconf for a collection /db/tbrc
>> 
>>> <collection xmlns="http://exist-db.org/collection-config/1.0">
>>> <default-permissions resource="0774" collection="0774"/>
>>> <triggers>
>>> <trigger event="store,remove,update" class="org.exist.versioning.VersioningTrigger">
>>> <parameter name="overwrite" value="no"/>
>>> </trigger>
>>> </triggers>
>>> </collection>
>> 
>> I shutdown the DB and removed the redundant lines from the conf.xml and restarted the DB and then uploaded a file via the admin.xq Browse Collections and also uploaded a file via the client.sh command line put. In both instances I am still seeing:
>> 
>> "rw-r--r--"
>> 
>> For the resulting permissions. Only the user that uploaded can delete and no updates can happen.
>> 
>> 
>> 
>> -- 
>> Dmitriy Shabanov
> 
> 
> 
> 
> -- 
> Dmitriy Shabanov

Re: [Exist-development] default perms in collection.xconf do not seem to work

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

add default-permissions to each collection.xconf, not just top one.

I did write: it will look up to first configuration. But if that first
configuration don't have default-permission, then it use internal-default
one. That is current behavior.

On Tue, Oct 18, 2011 at 12:11 PM, Chris Tomlinson <
chr...@gm...> wrote:

> Dmitriy,
>
> The collections are structured as:
>
> */db/tbrc*
> */db/tbrc/A*
> */db/tbrc/B*
>
> and I have *collection.xconf* files for */db/tbrc* and */db/tbrc/A* and *
> /db/tbrc/B*. There is no *collection.xconf* for */db*
>
> However, for the purposes of this test I only put the*<default-permissions/>
> * in the *collection.xconf* for */db/tbrc* and then did the uploads into
> the collection* /db/tbrc*. I would assume the presence of *
> collection.xconf* files below */db/tbrc* would have effect on the uploads
> into */db/tbrc*.
>
> I note that back on 4 Aug, Efraim Feinstein remarked:
>
> (3) The obvious way to do (2) is the default-permissions element in
> conf.xml. As far as I can tell, setting the resource parameter to 770 is
> doing nothing.
>
>
> So apparently he was having difficulties in the same area. I saw no replies
> regarding his observation.
>
> Chris
>
>
>
> On Oct 18, 2011, at 12:47 PM, Dmitriy Shabanov wrote:
>
> is it only collection.xconf that you have?
>
> On Tue, Oct 18, 2011 at 11:23 AM, Chris Tomlinson <
> chr...@gm...> wrote:
>
>>
>> I added the defaults as you indicated to the collection.xconf for a
>> collection /db/tbrc
>>
>> <collection xmlns="http://exist-db.org/collection-config/1.0">
>> <default-permissions resource="0774" collection="0774"/>
>> <triggers>
>> <trigger event="store,remove,update" class="
>> org.exist.versioning.VersioningTrigger">
>> <parameter name="overwrite" value="no"/>
>> </trigger>
>> </triggers>
>> </collection>
>>
>>
>> I shutdown the DB and removed the redundant lines from the conf.xml and
>> restarted the DB and then uploaded a file via the admin.xq Browse
>> Collections and also uploaded a file via the client.sh command line put. In
>> both instances I am still seeing:
>>
>> "rw-r--r--"
>>
>> For the resulting permissions. Only the user that uploaded can delete and
>> no updates can happen.
>>
>>
>>
> --
> Dmitriy Shabanov
>
>
>


-- 
Dmitriy Shabanov

Re: [Exist-development] default perms in collection.xconf do not seem to work

[Chris T. <chr...@gm...>]

Dmitriy,

The collections are structured as:

/db/tbrc
/db/tbrc/A
/db/tbrc/B

and I have collection.xconf files for /db/tbrc and /db/tbrc/A and /db/tbrc/B. There is no collection.xconf for /db

However, for the purposes of this test I only put the <default-permissions/> in the collection.xconf for /db/tbrc and then did the uploads into the collection /db/tbrc. I would assume the presence of collection.xconf files below /db/tbrc would have effect on the uploads into /db/tbrc.

I note that back on 4 Aug, Efraim Feinstein remarked:

> (3) The obvious way to do (2) is the default-permissions element in 
> conf.xml. As far as I can tell, setting the resource parameter to 770 is 
> doing nothing.

So apparently he was having difficulties in the same area. I saw no replies regarding his observation.

Chris



On Oct 18, 2011, at 12:47 PM, Dmitriy Shabanov wrote:

> is it only collection.xconf that you have?
> 
> On Tue, Oct 18, 2011 at 11:23 AM, Chris Tomlinson <chr...@gm...> wrote:
> 
> I added the defaults as you indicated to the collection.xconf for a collection /db/tbrc
> 
>> <collection xmlns="http://exist-db.org/collection-config/1.0">
>> <default-permissions resource="0774" collection="0774"/>
>> <triggers>
>> <trigger event="store,remove,update" class="org.exist.versioning.VersioningTrigger">
>> <parameter name="overwrite" value="no"/>
>> </trigger>
>> </triggers>
>> </collection>
> 
> I shutdown the DB and removed the redundant lines from the conf.xml and restarted the DB and then uploaded a file via the admin.xq Browse Collections and also uploaded a file via the client.sh command line put. In both instances I am still seeing:
> 
> "rw-r--r--"
> 
> For the resulting permissions. Only the user that uploaded can delete and no updates can happen.
> 
> 
> 
> -- 
> Dmitriy Shabanov

Re: [Exist-development] default perms in collection.xconf do not seem to work

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

is it only collection.xconf that you have?

On Tue, Oct 18, 2011 at 11:23 AM, Chris Tomlinson <
chr...@gm...> wrote:

>
> I added the defaults as you indicated to the collection.xconf for a
> collection /db/tbrc
>
> <collection xmlns="http://exist-db.org/collection-config/1.0">
> <default-permissions resource="0774" collection="0774"/>
> <triggers>
> <trigger event="store,remove,update" class="
> org.exist.versioning.VersioningTrigger">
> <parameter name="overwrite" value="no"/>
> </trigger>
> </triggers>
> </collection>
>
>
> I shutdown the DB and removed the redundant lines from the conf.xml and
> restarted the DB and then uploaded a file via the admin.xq Browse
> Collections and also uploaded a file via the client.sh command line put. In
> both instances I am still seeing:
>
> "rw-r--r--"
>
> For the resulting permissions. Only the user that uploaded can delete and
> no updates can happen.
>
>
>
-- 
Dmitriy Shabanov

[Exist-development] default perms in collection.xconf do not seem to work

[Chris T. <chr...@gm...>]

Dmitriy,

I added the defaults as you indicated to the collection.xconf for a collection /db/tbrc

> <collection xmlns="http://exist-db.org/collection-config/1.0">
> <default-permissions resource="0774" collection="0774"/>
> <triggers>
> <trigger event="store,remove,update" class="org.exist.versioning.VersioningTrigger">
> <parameter name="overwrite" value="no"/>
> </trigger>
> </triggers>
> </collection>

I shutdown the DB and removed the redundant lines from the conf.xml and restarted the DB and then uploaded a file via the admin.xq Browse Collections and also uploaded a file via the client.sh command line put. In both instances I am still seeing:

"rw-r--r--"

For the resulting permissions. Only the user that uploaded can delete and no updates can happen.

What am I doing wrong?

Thanks,
Chris



On Oct 18, 2011, at 11:29 AM, Chris Tomlinson wrote:

> Dmitriy,
> 
> Thanks. The per collection approach makes sense - does an explicit default at /db/A apply to children with out defaults like /db/A/B and /db/A/C/D and so on? 
> 
> It still seems that "u" means updatable and "w" means deletable in the code. Is this expected to remain true? Wolfgang's comment suggested otherwise saying that the new meaning was to be "rwx" which I assume meant that "w" would be deletable and updatable and "x" I guess would mean executable if the file was an xq or xqm otherwise I'm not sure what it would mean.
> 
> Thank again,
> Chris
> 
> 
> 
> On Oct 18, 2011, at 11:18 AM, Dmitriy Shabanov wrote:
> 
>> On Tue, Oct 18, 2011 at 10:14 AM, Chris Tomlinson <chr...@gm...> wrote:
>> Hello,
>> 
>> I'm looking into some issues surrounding permissions management in current trunk and am trying to make sure I understand what is intended and what is implemented in this area. I ran across this post of yours from 3 months ago and I wanted to know the status in this area is or whether it has been reconsidered.
>> 
>> In looking at org.exist.security.Permission.java it looks like it hasn't been worked on since 4 Aug and the "update" nomenclature is still in place and used in org.exist.security.AbstractUnixStylePermission.java which hasn't been worked on for even longer.
>> 
>> Trunk certainly still interprets the "u" perm as indicating that the file is updatable or not (versus deletable "w") and throws an error in the event that a user attempts to update and that flag isn't set for the user, group or other as appropriate.
>> 
>> Is this the behavior we can expect as trunk morphs into 1.6 or are there more changes on the way for org.exist.security?
>> 
>> I also seem to not understand the semantics of the <db-connection/> <default-permissions collection="0774" resource="0774" /> in the conf.xml file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't seem to make any difference. For example, when I upload a file via the http://localhost:8080/exist/admin/admin.xql > Browse collections interface I get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have expected. The same is true when running java client from the command line.
>> 
>> This redundant and should be cleaned up.
>> 
>> 
>> We have need of being able to upload files and the resulting permissions need to be "rwuruwr--" by default. How do we achieve this via the admin.xql or the command line client?
>>  
>> 
>> You should use:
>> 
>> ....
>> eXist has no "create index" command. Instead, indexes are configured in collection-specific configuration files. These files are stored as standard XML documents in the system collection: /db/system/config, which can be accessed like any other document (e.g. using the Admin interface or Java Client). In addition to defining settings for indexing collections, the configuration document specifies collection-specific other settings such as triggers or default permissions.
>> .... 
>> 
>> I didn't find any details at docs, so here some:
>> 
>> <collection xmlns="http://exist-db.org/collection-config/1.0">
>>     <default-permissions resource="0774" collection="0774"/>
>>      ....
>> </collection>
>> 
>> by this you can define default permissions per collection.
>> 
>> -- 
>> Dmitriy Shabanov
> 

Re: [Exist-development] Confused about permissions and defaults for XQuery files

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

On Tue, Oct 18, 2011 at 10:44 AM, Chris Tomlinson <
chr...@gm...> wrote:

> Thanks. The per collection approach makes sense - does an explicit default
> at /db/A apply to children with out defaults like /db/A/B and /db/A/C/D and
> so on?
>

Yes, should be to closed parent collection with defined configuration.


>
> It still seems that "u" means updatable and "w" means deletable in the
> code. Is this expected to remain true? Wolfgang's comment suggested
> otherwise saying that the new meaning was to be "rwx" which I assume meant
> that "w" would be deletable and updatable and "x" I guess would mean
> executable if the file was an xq or xqm otherwise I'm not sure what it would
> mean.
>

for xml resource it should be 'rwu', for binary & collections (or only
xquery scripts, not clear for me) 'rwx'

-- 
Dmitriy Shabanov

Re: [Exist-development] Confused about permissions and defaults for XQuery files

[Chris T. <chr...@gm...>]

Dmitriy,

Thanks. The per collection approach makes sense - does an explicit default at /db/A apply to children with out defaults like /db/A/B and /db/A/C/D and so on? 

It still seems that "u" means updatable and "w" means deletable in the code. Is this expected to remain true? Wolfgang's comment suggested otherwise saying that the new meaning was to be "rwx" which I assume meant that "w" would be deletable and updatable and "x" I guess would mean executable if the file was an xq or xqm otherwise I'm not sure what it would mean.

Thank again,
Chris



On Oct 18, 2011, at 11:18 AM, Dmitriy Shabanov wrote:

> On Tue, Oct 18, 2011 at 10:14 AM, Chris Tomlinson <chr...@gm...> wrote:
> Hello,
> 
> I'm looking into some issues surrounding permissions management in current trunk and am trying to make sure I understand what is intended and what is implemented in this area. I ran across this post of yours from 3 months ago and I wanted to know the status in this area is or whether it has been reconsidered.
> 
> In looking at org.exist.security.Permission.java it looks like it hasn't been worked on since 4 Aug and the "update" nomenclature is still in place and used in org.exist.security.AbstractUnixStylePermission.java which hasn't been worked on for even longer.
> 
> Trunk certainly still interprets the "u" perm as indicating that the file is updatable or not (versus deletable "w") and throws an error in the event that a user attempts to update and that flag isn't set for the user, group or other as appropriate.
> 
> Is this the behavior we can expect as trunk morphs into 1.6 or are there more changes on the way for org.exist.security?
> 
> I also seem to not understand the semantics of the <db-connection/> <default-permissions collection="0774" resource="0774" /> in the conf.xml file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't seem to make any difference. For example, when I upload a file via the http://localhost:8080/exist/admin/admin.xql > Browse collections interface I get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have expected. The same is true when running java client from the command line.
> 
> This redundant and should be cleaned up.
> 
> 
> We have need of being able to upload files and the resulting permissions need to be "rwuruwr--" by default. How do we achieve this via the admin.xql or the command line client?
>  
> 
> You should use:
> 
> ....
> eXist has no "create index" command. Instead, indexes are configured in collection-specific configuration files. These files are stored as standard XML documents in the system collection: /db/system/config, which can be accessed like any other document (e.g. using the Admin interface or Java Client). In addition to defining settings for indexing collections, the configuration document specifies collection-specific other settings such as triggers or default permissions.
> .... 
> 
> I didn't find any details at docs, so here some:
> 
> <collection xmlns="http://exist-db.org/collection-config/1.0">
>     <default-permissions resource="0774" collection="0774"/>
>      ....
> </collection>
> 
> by this you can define default permissions per collection.
> 
> -- 
> Dmitriy Shabanov

Re: [Exist-development] Confused about permissions and defaults for XQuery files

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

On Tue, Oct 18, 2011 at 10:14 AM, Chris Tomlinson <
chr...@gm...> wrote:

> Hello,
>
> I'm looking into some issues surrounding permissions management in current
> trunk and am trying to make sure I understand what is intended and what is
> implemented in this area. I ran across this post of yours from 3 months ago
> and I wanted to know the status in this area is or whether it has been
> reconsidered.
>
> In looking at org.exist.security.Permission.java it looks like it hasn't
> been worked on since 4 Aug and the "update" nomenclature is still in place
> and used in org.exist.security.AbstractUnixStylePermission.java which hasn't
> been worked on for even longer.
>
> Trunk certainly still interprets the "u" perm as indicating that the file
> is updatable or not (versus deletable "w") and throws an error in the event
> that a user attempts to update and that flag isn't set for the user, group
> or other as appropriate.
>
> Is this the behavior we can expect as trunk morphs into 1.6 or are there
> more changes on the way for org.exist.security?
>
> I also seem to not understand the semantics of the <db-connection/>
> <default-permissions collection="0774" resource="0774" /> in the conf.xml
> file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't
> seem to make any difference. For example, when I upload a file via the
> http://localhost:8080/exist/admin/admin.xql > Browse collections interface
> I get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have
> expected. The same is true when running java client from the command line.
>

This redundant and should be cleaned up.


> We have need of being able to upload files and the resulting permissions
> need to be "rwuruwr--" by default. How do we achieve this via the admin.xql
> or the command line client?
>


You should use:

....
eXist has no "create index" command. Instead, indexes are configured in
collection-specific configuration files. These files are stored as standard
XML documents in the system collection: /db/system/config, which can be
accessed like any other document (e.g. using the Admin interface or Java
Client). In addition to defining settings for indexing collections, the
configuration document specifies collection-specific other settings such as
triggers or *default permissions*.
....

I didn't find any details at docs, so here some:

<collection xmlns="http://exist-db.org/collection-config/1.0">
    <default-permissions resource="0774" collection="0774"/>
     ....
</collection>

by this you can define default permissions per collection.

-- 
Dmitriy Shabanov

[Exist-development] Confused about permissions and defaults for XQuery files

[Chris T. <chr...@gm...>]

Hello,

I'm looking into some issues surrounding permissions management in current trunk and am trying to make sure I understand what is intended and what is implemented in this area. I ran across this post of yours from 3 months ago and I wanted to know the status in this area is or whether it has been reconsidered.

In looking at org.exist.security.Permission.java it looks like it hasn't been worked on since 4 Aug and the "update" nomenclature is still in place and used in org.exist.security.AbstractUnixStylePermission.java which hasn't been worked on for even longer.

Trunk certainly still interprets the "u" perm as indicating that the file is updatable or not (versus deletable "w") and throws an error in the event that a user attempts to update and that flag isn't set for the user, group or other as appropriate.

Is this the behavior we can expect as trunk morphs into 1.6 or are there more changes on the way for org.exist.security?

I also seem to not understand the semantics of the <db-connection/> <default-permissions collection="0774" resource="0774" /> in the conf.xml file. I have the above set in the conf.xml on trunk rev 15412 and it doesn't seem to make any difference. For example, when I upload a file via the http://localhost:8080/exist/admin/admin.xql > Browse collections interface I get permissions: "rw-r--r--" rather than "rwuruwr--" which I would have expected. The same is true when running java client from the command line.

We have need of being able to upload files and the resulting permissions need to be "rwuruwr--" by default. How do we achieve this via the admin.xql or the command line client?

Thanks,
Chris


On Jul 7, 2011, at 12:33 PM, Wolfgang Meier wrote:

>> #1: Why does my controller.xql file need guest update permissions for
>> regular web browsing?
> 
> For XQuery resources, the permission flags are now interpreted as rwx
> instead of the old rwu. We're in the process of changing this
> everywhere. The documentation is a bit behind.
> 
> Wolfgang
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-development] gradle vs maven

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

yeap, he was pessimistic during maven talks. And he wants to leave as it or
better build control then maven can provide as ant have. That what I did see
=)

On Mon, Oct 17, 2011 at 10:22 PM, Adam Retter <ad...@ex...> wrote:

> Did I miss something where Dannes said he wanted something?
>

-- 
Dmitriy Shabanov

Re: [Exist-development] gradle vs maven

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

Did I miss something where Dannes said he wanted something?

On 17 October 2011 17:25, Dmitriy Shabanov <sha...@gm...> wrote:
> So, we have two fronts: one wants how, another - what.
> Is it possible to find consensus? The answer is not clear for me after year
> and 9 months =)
>
> Is it possible to have top level of Gradle declarative? My guess, yes. That
> can give features that Dannes want and keep it declarative as Adam would
> like to have.
>
> Adam, did Gradle change after your last look on it?
>
> Dannes, your notes?
>
> Others?
>
> On Mon, Oct 17, 2011 at 5:36 PM, Adam Retter <ad...@ex...> wrote:
>>
>> I did consider in some detail Gradle, Buildr and Ivy+Ant before
>> settling on Maven.
>>
>> The main advantage to Gradle is complete flexibility as its written in
>> programming code i.e. Groovy.
>> The main disadvantage to Gradle is complete flexibilty and having to
>> write code in Groovy.
>>
>> I decided on Maven and not Gradle because -
>> 1) Many more people know Maven than Gradle.
>> 2) The tooling and support for Maven is much much better than Gradle.
>> 3) I didnt want to have to learn Groovy and ship a Groovy run-time
>> with my application.
>> 4) I think a build system should be declarative, i.e. I want to build
>> these things, NOT how to build these things. Maven allows you to
>> describe what things to build, Gradle allows complete flexibility a
>> bit like Ant but more so, I didnt want to end up in the situation
>> where we are with Ant now, i.e. maintaining thousands of lines
>> describing how to build something.
>>
>> I did actually put together a presentation for the eXist developers
>> meetup in Prague, but there was not actually enough time to give it
>> formally - you can find my slides for that here -
>> http://www.adamretter.org.uk/presentations.xml
>>
>
> --
> Dmitriy Shabanov
>



-- 
Adam Retter

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

Re: [Exist-development] gradle vs maven

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

So, we have two fronts: one wants how, another - what.
Is it possible to find consensus? The answer is not clear for me after year
and 9 months =)

Is it possible to have top level of Gradle declarative? My guess, yes. That
can give features that Dannes want and keep it declarative as Adam would
like to have.

Adam, did Gradle change after your last look on it?

Dannes, your notes?

Others?

On Mon, Oct 17, 2011 at 5:36 PM, Adam Retter <ad...@ex...> wrote:

> I did consider in some detail Gradle, Buildr and Ivy+Ant before
> settling on Maven.
>
> The main advantage to Gradle is complete flexibility as its written in
> programming code i.e. Groovy.
> The main disadvantage to Gradle is complete flexibilty and having to
> write code in Groovy.
>
> I decided on Maven and not Gradle because -
> 1) Many more people know Maven than Gradle.
> 2) The tooling and support for Maven is much much better than Gradle.
> 3) I didnt want to have to learn Groovy and ship a Groovy run-time
> with my application.
> 4) I think a build system should be declarative, i.e. I want to build
> these things, NOT how to build these things. Maven allows you to
> describe what things to build, Gradle allows complete flexibility a
> bit like Ant but more so, I didnt want to end up in the situation
> where we are with Ant now, i.e. maintaining thousands of lines
> describing how to build something.
>
> I did actually put together a presentation for the eXist developers
> meetup in Prague, but there was not actually enough time to give it
> formally - you can find my slides for that here -
> http://www.adamretter.org.uk/presentations.xml
>
>
-- 
Dmitriy Shabanov

Re: [Exist-development] gradle vs maven

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

I did consider in some detail Gradle, Buildr and Ivy+Ant before
settling on Maven.

The main advantage to Gradle is complete flexibility as its written in
programming code i.e. Groovy.
The main disadvantage to Gradle is complete flexibilty and having to
write code in Groovy.

I decided on Maven and not Gradle because -
1) Many more people know Maven than Gradle.
2) The tooling and support for Maven is much much better than Gradle.
3) I didnt want to have to learn Groovy and ship a Groovy run-time
with my application.
4) I think a build system should be declarative, i.e. I want to build
these things, NOT how to build these things. Maven allows you to
describe what things to build, Gradle allows complete flexibility a
bit like Ant but more so, I didnt want to end up in the situation
where we are with Ant now, i.e. maintaining thousands of lines
describing how to build something.

I did actually put together a presentation for the eXist developers
meetup in Prague, but there was not actually enough time to give it
formally - you can find my slides for that here -
http://www.adamretter.org.uk/presentations.xml



On 17 October 2011 07:14, Dmitriy Shabanov <sha...@gm...> wrote:
> Hello,
> It here http://www.gradle.org/
>
> thoughts?
> --
> Dmitriy Shabanov
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> 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

[Exist-development] gradle vs maven

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

Hello,

It here http://www.gradle.org/

thoughts?

-- 
Dmitriy Shabanov

Re: [Exist-development] doc-available() should not produce true for non XML files

[Leif-Jöran O. <lj...@ex...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Den 2011-10-06 22:09, Adam Retter skrev:
> You are correct in your understanding of the XQuery spec, and I could
> easily make this change and probably should. But I do wonder how many
> people rely on this existing bad behaviour.
> 
> Its tricky because eXist-db has no notion of both 'XML Documents' and
> 'Binary documents'. Perhaps we should start referring to Binary
> documents as Binary resources.
> 
> I am reluctant to fix this, because calling doc-available() and getting
> true() for a URI that points to a binary resource makes perfect sense to
> me. Unfortunately its not compliant with the specification, however the
> specification has no consideration whatsoever of Binary
> documents/resources because its the XML Query specification.
> 
> We perhaps need an xmldb:doc-exists() function to replace this once we
> bring fn:doc-available() inline with the specs.

Well, we added util:binary-doc-available quite some time ago just to
encompass this.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOlu6/hcIn5aVXOPIRAttaAJ9W7aG5NJJD6csZmhFmUHrhoRIuBQCgiHiV
SXsX8ZvelZ2Ealun5GRbLAc=
=9OH/
-----END PGP SIGNATURE-----

Re: [Exist-development] doc-available() should not produce true for non XML files

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

You are correct in your understanding of the XQuery spec, and I could easily
make this change and probably should. But I do wonder how many people rely
on this existing bad behaviour.

Its tricky because eXist-db has no notion of both 'XML Documents' and
'Binary documents'. Perhaps we should start referring to Binary documents as
Binary resources.

I am reluctant to fix this, because calling doc-available() and getting
true() for a URI that points to a binary resource makes perfect sense to
me. Unfortunately its not compliant with the specification, however the
specification has no consideration whatsoever of Binary documents/resources
because its the XML Query specification.

We perhaps need an xmldb:doc-exists() function to replace this once we bring
fn:doc-available() inline with the specs.


2011/10/6 Вячеслав Седов <sch...@gm...>

> hi,
>
> if (doc-available($file-name)) then doc($file-name) else
> util:binary-doc($file-name) (: where $file-name point to xquery module
> :) produce error like this
>
>  Document /db/test/backup.xq is a binary resource, not an XML
> document. Please consider using the function util:binary-doc() to
> retrieve a reference to it.
>
> but here http://www.w3.org/TR/xpath-functions/#func-doc-available
>
> we can see
>
> "15.5.5 fn:doc-available
>
> fn:doc-available($uri as xs:string?) as xs:boolean
> Summary: The function returns true if and only if the function call
> fn:doc($uri) would return a document node.
>
> If $uri is an empty sequence, this function returns false.
>
> If a call on fn:doc($uri) would return a document node, this function
> returns true.
>
> If $uri is not a valid URI according to the rules applied by the
> implementation of fn:doc, an error is raised [err:FODC0005].
>
> Otherwise, this function returns false.
>
> If this function returns true, then calling fn:doc($uri) within the
> same ·execution scope· must return a document node. However, if
> non-stable processing has been selected for the fn:doc function, this
> guarantee is lost."
>
> with best wishes,
> Slav
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> 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] doc-available() should not produce true for non XML files

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

Slav,

Could you confirm for the list which version of eXist you've seen the
incorrect behavior on?

Cheers,
Joe

2011/10/6 Вячеслав Седов <sch...@gm...>:
> hi,
>
> if (doc-available($file-name)) then doc($file-name) else
> util:binary-doc($file-name) (: where $file-name point to xquery module
> :) produce error like this
>
>  Document /db/test/backup.xq is a binary resource, not an XML
> document. Please consider using the function util:binary-doc() to
> retrieve a reference to it.
>
> but here http://www.w3.org/TR/xpath-functions/#func-doc-available
>
> we can see
>
> "15.5.5 fn:doc-available
>
> fn:doc-available($uri as xs:string?) as xs:boolean
> Summary: The function returns true if and only if the function call
> fn:doc($uri) would return a document node.
>
> If $uri is an empty sequence, this function returns false.
>
> If a call on fn:doc($uri) would return a document node, this function
> returns true.
>
> If $uri is not a valid URI according to the rules applied by the
> implementation of fn:doc, an error is raised [err:FODC0005].
>
> Otherwise, this function returns false.
>
> If this function returns true, then calling fn:doc($uri) within the
> same ·execution scope· must return a document node. However, if
> non-stable processing has been selected for the fn:doc function, this
> guarantee is lost."
>
> with best wishes,
> Slav

[Exist-development] doc-available() should not produce true for non XML files

[Вячеслав С. <sch...@gm...>]

hi,

if (doc-available($file-name)) then doc($file-name) else
util:binary-doc($file-name) (: where $file-name point to xquery module
:) produce error like this

 Document /db/test/backup.xq is a binary resource, not an XML
document. Please consider using the function util:binary-doc() to
retrieve a reference to it.

but here http://www.w3.org/TR/xpath-functions/#func-doc-available

we can see

"15.5.5 fn:doc-available

fn:doc-available($uri as xs:string?) as xs:boolean
Summary: The function returns true if and only if the function call
fn:doc($uri) would return a document node.

If $uri is an empty sequence, this function returns false.

If a call on fn:doc($uri) would return a document node, this function
returns true.

If $uri is not a valid URI according to the rules applied by the
implementation of fn:doc, an error is raised [err:FODC0005].

Otherwise, this function returns false.

If this function returns true, then calling fn:doc($uri) within the
same ·execution scope· must return a document node. However, if
non-stable processing has been selected for the fn:doc function, this
guarantee is lost."

with best wishes,
Slav