(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