[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