exist-development

[Exist-development] And yet another security/Ant issue....addendum

[Andrzej J. T. <an...@ch...>]

BTW, I create the myuser like this (before I change the admin password from empty):

<exist:adduser failonerror="false" uri="${exist.url}/xmlrpc/db" user="admin" password=""
name="myuser" secret="${password}" home="/db" primaryGroup="dba"/>

That should make myuser a DBA, right?

Logging into the admin web page shows that the user is not a DBA, since it can't do a database
shutdown.  But the user list (both in the admin web page and in the Java client) shows myuser as a
member of the dba group.

....A

> I use an ant task to run an xquery as follows:
> 
> <exist:xquery queryfile="${temp.dir}/importData.xql" outputproperty="importResults"
> uri="${exist.url}/xmlrpc/db" user="myuser" password="${password}"> </exist:xquery>
> 
> but it the fails with the following:
> 
> BUILD FAILED
> /home/andrzej/build.xml:1747: XMLDB exception caught while executing query: Permission denied,
> calling user 'myuser' must be a DBA to call this function. [at line 75, column 23, source: String]
> 
> The line in the xquery that is failing is:
> 
> 	let $list   := file:directory-list( $dir, "*.xml" )
> 
> which requires DBA permissions as expected.
> 
> The problem is that the ant task was initiated using user "myuser" which is part of the dba
> group...and thus should be a DBA, right?
> 
> This used to work fine....but is now broken with the new security stuff.
> 
> Any idea why myuser isn't being seen as having dba permissions when executing an xquery using the
> ant task?


-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] And yet another security/Ant issue....addendum

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

empty password "disable" account, it must have some chars.

On Fri, Apr 29, 2011 at 8:03 PM, Andrzej Jan Taramina
<an...@ch...>wrote:

> BTW, I create the myuser like this (before I change the admin password from
> empty):
>
> <exist:adduser failonerror="false" uri="${exist.url}/xmlrpc/db"
> user="admin" password=""
> name="myuser" secret="${password}" home="/db" primaryGroup="dba"/>
>
> That should make myuser a DBA, right?
>
> Logging into the admin web page shows that the user is not a DBA, since it
> can't do a database
> shutdown.  But the user list (both in the admin web page and in the Java
> client) shows myuser as a
> member of the dba group.
>
> ....A
>
> > I use an ant task to run an xquery as follows:
> >
> > <exist:xquery queryfile="${temp.dir}/importData.xql"
> outputproperty="importResults"
> > uri="${exist.url}/xmlrpc/db" user="myuser" password="${password}">
> </exist:xquery>
> >
> > but it the fails with the following:
> >
> > BUILD FAILED
> > /home/andrzej/build.xml:1747: XMLDB exception caught while executing
> query: Permission denied,
> > calling user 'myuser' must be a DBA to call this function. [at line 75,
> column 23, source: String]
> >
> > The line in the xquery that is failing is:
> >
> >       let $list   := file:directory-list( $dir, "*.xml" )
> >
> > which requires DBA permissions as expected.
> >
> > The problem is that the ant task was initiated using user "myuser" which
> is part of the dba
> > group...and thus should be a DBA, right?
> >
> > This used to work fine....but is now broken with the new security stuff.
> >
> > Any idea why myuser isn't being seen as having dba permissions when
> executing an xquery using the
> > ant task?
>
>
> --
> Andrzej Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>



-- 
Dmitriy Shabanov

Re: [Exist-development] And yet another security/Ant issue....addendum

[Andrzej J. T. <an...@ch...>]

Dmitry:

> empty password "disable" account, it must have some chars.

You don't seem to understand how the adduser Ant task works.  The user/password attributes are for
the user that is performing the add.  On a new database that would be the admin user, which has no
password set, so you provide an empty password.

The user being added is specified by name/secret, in the example below myuser and the value of the
Ant variable ${password}. The password is not empty!

The issue is that the myuser is added, with the correct password.  You can log in as that user no
problem.  Both the web and java admin clients show myuser as being in the "dba" group.

But myuser does not have dba priviledges for some reason which is a big and a rather serious one in
my estimation.  If I'm logged in as myuser, I cannot do a file:directory-list( $dir, "*.xml" ) as it
fails on a permission problem.

This is a bug in the security implementation that needs fixing.

....A

> On Fri, Apr 29, 2011 at 8:03 PM, Andrzej Jan Taramina <an...@ch...
> <mailto:an...@ch...>> wrote:
> 
>     BTW, I create the myuser like this (before I change the admin password from empty):
> 
>     <exist:adduser failonerror="false" uri="${exist.url}/xmlrpc/db" user="admin" password=""
>     name="myuser" secret="${password}" home="/db" primaryGroup="dba"/>
> 
>     That should make myuser a DBA, right?
> 
>     Logging into the admin web page shows that the user is not a DBA, since it can't do a database
>     shutdown.  But the user list (both in the admin web page and in the Java client) shows myuser as a
>     member of the dba group.
> 
>     ....A
> 
>     > I use an ant task to run an xquery as follows:
>     >
>     > <exist:xquery queryfile="${temp.dir}/importData.xql" outputproperty="importResults"
>     > uri="${exist.url}/xmlrpc/db" user="myuser" password="${password}"> </exist:xquery>
>     >
>     > but it the fails with the following:
>     >
>     > BUILD FAILED
>     > /home/andrzej/build.xml:1747: XMLDB exception caught while executing query: Permission denied,
>     > calling user 'myuser' must be a DBA to call this function. [at line 75, column 23, source: String]
>     >
>     > The line in the xquery that is failing is:
>     >
>     >       let $list   := file:directory-list( $dir, "*.xml" )
>     >
>     > which requires DBA permissions as expected.
>     >
>     > The problem is that the ant task was initiated using user "myuser" which is part of the dba
>     > group...and thus should be a DBA, right?
>     >
>     > This used to work fine....but is now broken with the new security stuff.
>     >
>     > Any idea why myuser isn't being seen as having dba permissions when executing an xquery using the
>     > ant task?
> 
> 
>     --
>     Andrzej Taramina
>     Chaeron Corporation: Enterprise System Solutions
>     http://www.chaeron.com
> 
> 
> 
> 
> -- 
> Dmitriy Shabanov


-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] And yet another security/Ant issue....addendum

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

On Sat, Apr 30, 2011 at 7:43 AM, Andrzej Jan Taramina
<an...@ch...>wrote:

> Dmitry:
>
> > empty password "disable" account, it must have some chars.
>
> You don't seem to understand how the adduser Ant task works.  The
> user/password attributes are for
> the user that is performing the add.  On a new database that would be the
> admin user, which has no
> password set, so you provide an empty password.
>
> The user being added is specified by name/secret, in the example below
> myuser and the value of the
> Ant variable ${password}. The password is not empty!
>
> The issue is that the myuser is added, with the correct password.  You can
> log in as that user no
> problem.  Both the web and java admin clients show myuser as being in the
> "dba" group.
>
> But myuser does not have dba priviledges for some reason which is a big and
> a rather serious one in
> my estimation.  If I'm logged in as myuser, I cannot do a
> file:directory-list( $dir, "*.xml" ) as it
> fails on a permission problem.
>
> This is a bug in the security implementation that needs fixing.
>

That is not a security issue if you see it in DBA group. Did you check user
from running script? (let's say one line before file:directory-list)

-- 
Dmitriy Shabanov

Re: [Exist-development] And yet another security/Ant issue...IT's A BUG IN SECURITY!

[Andrzej J. T. <an...@ch...>]

Dmitry:

> That is not a security issue if you see it in DBA group. Did you check user from running script?
> (let's say one line before file:directory-list)

THIS IS A BUG IN SECURITY!!!!!!

If you have noticed over the past few years, when I report a bug, I typically have done a lot of
testing prior to mentioning it, to be sure that it's a bug, and to provide enough information to
allow for the replication of the problem.

If you create a new user in the dba group using the Ant adduser task as follows:

<target name="create-users-test" depends="init" description="add test user for Dmitry">
   <exist:adduser failonerror="false" uri="${exist.url}/xmlrpc/db" user="admin"
		  password="adminpswd" name="test" secret="test" home="/db" primaryGroup="dba"/>
		
   <exist:users failonerror="false" uri="${exist.url}/xmlrpc/db" user="admin"
                password="adminpswd" outputproperty="users"/>
		
   <echo>eXist Users: ${users}</echo>
		
</target>

(change adminpswd to whatever your admin users password really is)

Then the user is created, and is part of the dba group.

If you then try to immediately log in as that user and do something that requires DBA permissions,
it will fail.  Try logging in as test on the admin web page and try to do a shutdown or list running
jobs. The request will fail telling you that your user (test in my example) does not have DBA
permissions.

I did a bit more testing today.  If you shut down and restart eXist after you add the user, then
things will work properly.  That is, if you then log in as test, you can perform dba-restricted things.

If you add a user using the Admin web page, the same thing happens. You have to restart the database
before it will show as having DBA permissions. So this bug is not restricted to just the Ant task
implementation of adduser.

So there is a bug in the security implementation, probably do to with how user credentials are
cached, since a restart seems to fix the issue.

This is all on the latest/greatest trunk as of this morning. And it wasn't there before you
implemented the new security scheme.

So let me repeat myself so that you understand:

THIS IS A BUG IN SECURITY!!!!!!
THIS IS A BUG IN SECURITY!!!!!!
THIS IS A BUG IN SECURITY!!!!!!

Thank you! ;-)

....Andrzej

>     You don't seem to understand how the adduser Ant task works.  The user/password attributes are for
>     the user that is performing the add.  On a new database that would be the admin user, which has no
>     password set, so you provide an empty password.
> 
>     The user being added is specified by name/secret, in the example below myuser and the value of the
>     Ant variable ${password}. The password is not empty!
> 
>     The issue is that the myuser is added, with the correct password.  You can log in as that user no
>     problem.  Both the web and java admin clients show myuser as being in the "dba" group.
> 
>     But myuser does not have dba priviledges for some reason which is a big and a rather serious one in
>     my estimation.  If I'm logged in as myuser, I cannot do a file:directory-list( $dir, "*.xml" ) as it
>     fails on a permission problem.
> 
>     This is a bug in the security implementation that needs fixing.
> 
> 


-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] And yet another security/Ant issue...IT's A BUG IN SECURITY!

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

> So there is a bug in the security implementation, probably do to with how user credentials are
> cached, since a restart seems to fix the issue.

The bug is easy to reproduce and you don't need Ant for it:

1) Launch a clean db
2) Use the Java admin client to create a user "administrator" and
assign it to the dba group
3) Log into the client as "administrator" and try to trigger a
shutdown -> permission denied!
4) Stop and restart the db
5) Repeat step 3) -> you are now allowed to shutdown

Wolfgang

Re: [Exist-development] And yet another security/Ant issue...IT's A BUG IN SECURITY!

[Andrzej J. T. <an...@ch...>]

Wolfgang:

> The bug is easy to reproduce and you don't need Ant for it:
> 
> 1) Launch a clean db
> 2) Use the Java admin client to create a user "administrator" and
> assign it to the dba group
> 3) Log into the client as "administrator" and try to trigger a
> shutdown -> permission denied!
> 4) Stop and restart the db
> 5) Repeat step 3) -> you are now allowed to shutdown

Yup....as I had mentioned you can do the same thing with the Admin Web App. Thanks for corroborating
this.

So like I said....it's a security/permissions bug, Dmitry! ;-)

LOL

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] And yet another security/Ant issue...IT's A BUG IN SECURITY!

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

fixed by http://exist.svn.sourceforge.net/exist/?rev=14356&view=rev

for future, you can answer my question or spend a lot of time to explain
that you are right, result will be same :-)

You did start with problem around xquery script, that can be because of two
different places, I did ask the question to understand what place is making
troubles ....

On Sat, Apr 30, 2011 at 9:14 PM, Andrzej Jan Taramina
<an...@ch...>wrote:

> Dmitry:
>
> > That is not a security issue if you see it in DBA group. Did you check
> user from running script?
> > (let's say one line before file:directory-list)
>
> THIS IS A BUG IN SECURITY!!!!!!
>
> If you have noticed over the past few years, when I report a bug, I
> typically have done a lot of
> testing prior to mentioning it, to be sure that it's a bug, and to provide
> enough information to
> allow for the replication of the problem.
>
> If you create a new user in the dba group using the Ant adduser task as
> follows:
>
> <target name="create-users-test" depends="init" description="add test user
> for Dmitry">
>   <exist:adduser failonerror="false" uri="${exist.url}/xmlrpc/db"
> user="admin"
>                  password="adminpswd" name="test" secret="test" home="/db"
> primaryGroup="dba"/>
>
>   <exist:users failonerror="false" uri="${exist.url}/xmlrpc/db"
> user="admin"
>                password="adminpswd" outputproperty="users"/>
>
>   <echo>eXist Users: ${users}</echo>
>
> </target>
>
> (change adminpswd to whatever your admin users password really is)
>
> Then the user is created, and is part of the dba group.
>
> If you then try to immediately log in as that user and do something that
> requires DBA permissions,
> it will fail.  Try logging in as test on the admin web page and try to do a
> shutdown or list running
> jobs. The request will fail telling you that your user (test in my example)
> does not have DBA
> permissions.
>
> I did a bit more testing today.  If you shut down and restart eXist after
> you add the user, then
> things will work properly.  That is, if you then log in as test, you can
> perform dba-restricted things.
>
> If you add a user using the Admin web page, the same thing happens. You
> have to restart the database
> before it will show as having DBA permissions. So this bug is not
> restricted to just the Ant task
> implementation of adduser.
>
> So there is a bug in the security implementation, probably do to with how
> user credentials are
> cached, since a restart seems to fix the issue.
>
> This is all on the latest/greatest trunk as of this morning. And it wasn't
> there before you
> implemented the new security scheme.
>
> So let me repeat myself so that you understand:
>
> THIS IS A BUG IN SECURITY!!!!!!
> THIS IS A BUG IN SECURITY!!!!!!
> THIS IS A BUG IN SECURITY!!!!!!
>
> Thank you! ;-)
>
> ....Andrzej
>
> >     You don't seem to understand how the adduser Ant task works.  The
> user/password attributes are for
> >     the user that is performing the add.  On a new database that would be
> the admin user, which has no
> >     password set, so you provide an empty password.
> >
> >     The user being added is specified by name/secret, in the example
> below myuser and the value of the
> >     Ant variable ${password}. The password is not empty!
> >
> >     The issue is that the myuser is added, with the correct password.
>  You can log in as that user no
> >     problem.  Both the web and java admin clients show myuser as being in
> the "dba" group.
> >
> >     But myuser does not have dba priviledges for some reason which is a
> big and a rather serious one in
> >     my estimation.  If I'm logged in as myuser, I cannot do a
> file:directory-list( $dir, "*.xml" ) as it
> >     fails on a permission problem.
> >
> >     This is a bug in the security implementation that needs fixing.
> >
> >
>


-- 
Dmitriy Shabanov