[Dachs-support] permission denied for schema after run imp for the first time

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Jan 18 08:27:39 CET 2018


Hi Carlos,

On Wed, Jan 17, 2018 at 02:40:58PM -0200, Carlos Adean wrote:
> I have been experiencing some permission issues with untrusted
> user. I really do not know when it started.
> 
> I think something is broke in our DaCHS installation, maybe after
> the last update (on June 2016).
> 
> After importing a new schema/table the user untrusted has no
> permission to usage the schema and I have to set it manually.

That's not a bug, that's a feature :-)

DaCHS uses three different database roles:

gavoadmin -- for ingesting data; this one has create and write
  permissions (within DaCHS, that's the "feed" profile)
gavo -- for queries generated by the service itself.  This cannot
  write most tables, but it can read all of them, including
  administrative tables like dc.users or dc.products (the "trusted"
  profile)
untrusted -- for queries coming in through TAP and similar
  mechanisms.  These queries are written by possibly mildly malicious
  external parties, and although there are some mechanisms in place
  to ensure only tables actually declared adql-accessible can be
  referenced from such queries, I thought it's a good idea to have
  another line of defence (the "untrusted" profile)

This means that by default only the database role gavo can read a
DaCHS-created table.

By extension, this is true for schemas as well.

To make a table (and its embedding schema) readable from untrusted,
just include an adql="True" in the opening tag table definition (I
suspect you had that before things... well... broke).  You'll have to
gavo imp -m after adding the attribute to update the permissions on
the database engine.

       -- Markus

PS: There is a snag in this system that I should warn against here, I
guess.  Schema permissions are determined *by RD*: If there is at
least one table in the RD with adql="True", the schema is made
untrusted-readable, otherwise it is made untrusted-unreadable.  This
scheme breaks when there are two RDs for one schema, where one has
adql tables and the other doesn't.  I could *probably* put in a sane
behaviour nevertheless based on in-DB table metadata, but for now
it's not there, so: just use exactly one RD per schema and don't
worry.



More information about the Dachs-support mailing list