(moved to qserv-l for posterity)
Hi Douglas,
There is a good reason to have at least two classes:
1. sysadmin: Setup/maintain a cluster
2. exec: query-execution-related use
This separates activity so that:
a. we can tell the difference in logs
b. mysql can prevent query-execution from doing sysadmin things
Additionally, there is good reason to separate usage from frontend and
worker specifically for the single-node shared mysqld case, so they
don't stomp on each other's work. I am tempted to argue that even on a
single node, different mysqld instances be used for master and worker
(which at first seems to limit possible crazy optimization for the
single-node case, but is probably just a different kind of limit).
Now, on top of that, there is a desire to use mysqld permissions for the
primary enforcement of end-user access control. I have a gut feeling
that this tactic will be unsuccessful, but its benefits (moving more
permissions/access management off our responsibility) are too seductive
to ignore, and I am in favor of giving it a shot to see if it could work.
We already have some code that passes the username from frontend to
worker to worker-mysqld. The 'qsmaster' is the default that the frontend
uses because that part of the code was written before we started using a
mysql-proxy (i.e., before a plausible username could be retrieved).
More food for thought: the qserv worker and master may do things that
are part of query execution, but that the end user should not be able to
access in a query. Like (1) checking the "objectId" index, (2)
building/destroying subchunks, (3) poking to see what databases and
chunks can be published. It is true that I am trying to eliminate (1)
and Serge would love to eliminate (2), but (3) is an example of a usage
that is read-only, non-sysadmin, and not pegged to a particular user.
I'm trying to deal with (3) now.
Anyway, at least think about it. I realized that I wasn't going to come
up with a permanent solution while hacking through (3), so I thought I'd
see if you had a grand scheme in mind.
-Daniel
On 08/22/2013 01:54 PM, Smith, Douglas A. wrote:
> Well, I think so far we only have mysql root for the creation
> of needed databases. And then qsmaster user for all qserv
> interactions.
>
> I think that is it? Do we need any more than that? I mean
> I think all we need is one username for all qserv use. Is there
> any other reason to need more than one?
>
> Douglas
>
>
> On 08/21/2013 07:30 PM, Wang, Daniel Liwei wrote:
>> Hi Douglas,
>>
>> Can we clear up the policy for mysql usernames?
>>
>> We've done very little to codify the roles for user names in mysqld.
>> Let's also set aside the access from the qms, because we want to shift
>> that to sqlite anyway.
>>
>> qsmaster: access (done by qserv worker) on behalf of the qserv
>> master/frontend
>> ???: access by qserv master/frontend
>> ???: access by qserv worker for its own needs (maintaining scratch db,
>> deciding how to export)
>>
>> Honestly, I'd like to think as little about this as possible, but since
>> I'm bumping into it while writing code for worker maintenance, it seems
>> like we should make this clear and explicit.
>>
>> -Daniel
>>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
|