So our project which is making heavy use of xmldb functionality continues on and we're still coming across features/surprises along the way.
XMLDB for those of you that don't (which is likely most readers of this as it's so little used) is a way of storing and retrieving xml documents by various different protocols (http/ftp/plsql/webdav) from within the database (I'm oversimplifying a lot here but the core bit of what it is about can probably be summarized like that). There are various oracle manuals and books on the topic (which run to hundreds/thousands of pages - which gives you some idea that there is a lot to it). To be frank it's difficult to find where to start with it a lot of the time and that is maybe what has held back a lot of customers from using it.
This week we've had some off problem with permissions which i thought i'd share.
So in our case we are loading and retrieving the xml documents via http/https calls
In a very basic example this url call shows the folders/files that exist at the top level in the repository
http://server:port/public - in our case this returns
And the public folder (just think of them like windows explorer folders) just contains 2 subfolders and no files.
With the issue we discovered we just wanted to add a new folder (which can be done in many ways) - but we did it with plsql
declare
retval boolean;
begin
retval := dbms_xdb.createfolder('/public/richdemo');
end;
/
So this should create a new folder under the top level for me - which indeed it does :
By default this folder just inherits permissions from the parent folder - i want to change that - so i create a new access control list via this code:
DECLARE
retBool BOOLEAN;
BEGIN
retBool:=DBMS_XDB.CreateResource('/public/richdemo/richdemoacl.xml','<acl
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd http://xmlns.oracle.com/xdb/acl.xsd"
>
<ace>
<grant>true</grant>
<principal>DOESNOTEXIST</principal>
<privilege>
<all/>
</privilege>
</ace>
<ace>
<grant>true</grant>
<principal>dav:owner</principal>
<privilege>
<all/>
</privilege>
</ace>
</acl>');
end;
/
commit
/
Again the acl itself is just a document inside the xdb repository (there is a chicken and egg thing developing here....)
So that acl is now created - next i have to apply that to the folder i just created
To do that i run this:
begin
dbms_xdb.setacl('/public/richdemo', '/public/richdemo/richdemoacl.xml');
end;
/
commit
/
So now i've locked down permissions so that dav:owner (i.e. me) and the user/role with the name "DOESNOTEXIST" (chosen for comic effect) have permission.
Now when i try and view it i should still be able to see it because i am the owner - but what actually appears is this
So the folder is not visible - but it should be. Now i've kind of given you a hint about what the problem may be by my choice of username earlier, in our case though we had complex ACL's and it was not at all obvious.
What we did have was a trace file - with this content
*** 2014-11-24 14:25:01.368
*** SESSION ID:(56.11) 2014-11-24 14:25:01.368
*** SERVICE NAME:(SYS$USERS) 2014-11-24 14:25:01.368
ACLProblem set to true, error2 set to 44416, clearing error
in internal exception handler, error2: 44416
Implying some kind of acl issue - but nothing more than that.
After much investigation we found that there was a missing role - so we added that
SQL> create role doesnotexist;
Role created.
Refreshing the http session (via ctrl F5) and the folder appeared again.
So it seems that any missing users/roles included in an acl effectively break the entire acl - this is not at all obvious - in the browser the folder is just missing - no errors at all.
Comments
Post a Comment