Menu
▾
▴
exist-development
|
From: Chris T. <chr...@gm...> - 2011-10-18 05:16:46
|
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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 05:33:31
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 05:44:37
|
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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 06:14:06
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 06:23:54
|
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 > |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 07:02:10
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 07:12:08
|
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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 07:17:48
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 07:26:05
|
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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 07:46:51
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 08:05:58
|
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 |
|
From: Wolfgang M. <wol...@ex...> - 2011-10-18 07:52:58
|
> 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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 08:34:19
|
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 |
|
From: Adam R. <ad...@ex...> - 2011-10-18 09:43:03
|
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 > |
|
From: Adam R. <ad...@ex...> - 2011-10-18 08:36:36
|
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 |
|
From: Chris T. <chr...@gm...> - 2011-10-18 09:06:49
|
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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 09:52:58
|
The code that response for that behaver was commened-out by rev 14670. I don't know why. Adam? method Collection.manageDocumentInformation On Tue, Oct 18, 2011 at 12:46 PM, Dmitriy Shabanov <sha...@gm...>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 |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 09:56:21
|
On Tue, Oct 18, 2011 at 12:52 PM, Wolfgang Meier <wol...@ex...>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. > > > Remove 'u' completely? Just checking to be sure, that's fine for me. -- Dmitriy Shabanov |
|
From: Adam R. <ad...@ex...> - 2011-10-18 11:08:47
|
On Oct 18, 2011 10:56 AM, "Dmitriy Shabanov" <sha...@gm...> wrote: > > On Tue, Oct 18, 2011 at 12:52 PM, Wolfgang Meier <wol...@ex...> 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. >> >> > > Remove 'u' completely? Just checking to be sure, that's fine for me. This is already done in a branch here. I need to check in, but first I need to fix all the tests that relied on bad permissions. > -- > 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 > |
|
From: Dmitriy S. <sha...@gm...> - 2011-10-18 10:01:26
|
On Tue, Oct 18, 2011 at 2:06 PM, Chris Tomlinson < chr...@gm...> wrote: > 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. > +1 to keep this feature. What security issue? human? let move it to mars then .... =) -- Dmitriy Shabanov |
|
From: Adam R. <ad...@ex...> - 2011-10-18 11:08:48
|
On Oct 18, 2011 10:06 AM, "Chris Tomlinson" <chr...@gm...> wrote: > > 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. Yes that is correct. I am not sure what Dmitriy is describing. > 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. This is an interesting argument and one that I am not deaf to. However I would like to know if there is a known mechanism in Unix for this? My approach would be permissions inheritance through our new acl's. Inheritance is not ready yet though. > 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. Your best option would be to run a small xquery that uses the sm:chmod function. > > 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 > > |
|
From: Hungerburg <pc...@my...> - 2011-10-18 11:22:32
|
Am 2011-10-18 13:08, schrieb Adam Retter: > This is an interesting argument and one that I am not deaf to. However I > would like to know if there is a known mechanism in Unix for this? The *nix mechanism is called "umask": it specifies the permissions that will be subtracted from the default/full, ie rw-rw-rw on files and rwxrwxrwx on directories, permissions. Its a per process setting that will be passed on to forked children. From wikipedia: "The addition of umask (in around 1978) allowed sites, groups, and individuals to chose their own defaults. Small close groups might choose 000, computer centers 022, security-conscious groups 077 or 066 for access to sub-directories under private directories." -- peter |
|
From: Adam R. <ad...@ex...> - 2011-10-18 13:14:53
|
Okay, but am I correct in thinking that umask is applied per user? i.e. it lives in the users profile? It is the mount point of the fs that defines the overarching degfault permissions right? The way 'default permissions' in eXist-db were implemented previously were neither per user or per mount. I think permission inheritance with ACL will render umask unneeded? On 18 October 2011 12:22, Hungerburg <pc...@my...> wrote: > Am 2011-10-18 13:08, schrieb Adam Retter: >> This is an interesting argument and one that I am not deaf to. However I >> would like to know if there is a known mechanism in Unix for this? > > The *nix mechanism is called "umask": it specifies the permissions that > will be subtracted from the default/full, ie rw-rw-rw on files and > rwxrwxrwx on directories, permissions. Its a per process setting that > will be passed on to forked children. > > From wikipedia: "The addition of umask (in around 1978) allowed sites, > groups, and individuals to chose their own defaults. Small close groups > might choose 000, computer centers 022, security-conscious groups 077 or > 066 for access to sub-directories under private directories." > > -- > peter > > > ------------------------------------------------------------------------------ > 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 |
|
From: Wolfgang M. <wol...@ex...> - 2011-10-18 11:25:37
|
> +1 to keep this feature. What security issue? human? let move it to mars then .... =) Well, what's the consequence of disabling the configurable default permissions? In the end, we'll need to introduce some mechanism to allow the user to change the permissions of uploaded resources. I already changed the package repository installer to automatically set +x on all xquery resources you upload. So in a way we're just moving the problem into the user interface. We need to extend every interface to allow the user to specify default permissions. Somehow, the old mechanism of defining default permissions on a collection basis was more consistent and thus, one could argue: more secure. Wolfgang |
|
From: Wolfgang M. <wol...@ex...> - 2011-10-18 11:31:43
|
> Somehow, the old mechanism of defining default permissions on a collection basis was more consistent and thus, one could argue: more secure. For example, with respect to the package repository, I could define the correct default permissions in two collection.xconf, one for the top collection, and one for the collection containing the XQuery modules. This way, the installer would not have to bother with setting permissions and the setup would be easy to understand and change for the package developer. Wolfgang |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X