Flux-core: flux should get special user roles from config file

[garlick]

The userdb module is currently configured via flux module load command line, and with "live tools" flux user CMD ....

A better strategy would be to configure it with a config file. Instead of tools to make live changes, there should be a way to tell userdb to reread the config file. (instance owner runs flux config reload userdb or something like that?)

There would also be a performance benefit if we could load it across the instance rather than just on rank 0, since it is consulted every time a user other than the instance owner connects.

[grondo]

A generic config or similar command to tell modules to reload configuration (and be able to update config location) would be very useful!

[garlick]

Renaming issue to reflect the idea that userdb might just go away and be replaced with a config file read directly by connector-local and future modules of that sort.

[grondo]

Ah, good idea!

What is the main use case for the userdb and roles (besides the obvious OWNER and USER roles?) Is it that certain staff (e.g. hotline) could be given more limited roles than OWNER to manipulate priorities for example, or access kvs directly?

Could this be accomplished with sudo commands as we do now?

If not, then what is the strategy when a new hotline user is added to the config -- we'll need a way to force the connector-local and related modules to reload config. I don't think it would be feasible to wait until the next system instance restart.

[grondo]

It might also be nice if configuration allowed roles to be set by membership in Unix groups (e.g. FLUX_ROLE_ADMIN is inherited if you are in group flux). This would allow a more static configuration, and sites could manage roles using their chosen method for managing users and groups.

[garlick]

What is the main use case for the userdb and roles (besides the obvious OWNER and USER roles?) Is it that certain staff (e.g. hotline) could be given more limited roles than OWNER to manipulate priorities for example, or access kvs directly?

Yep, or cancel jobs.

Using groups to assign roles makes a ton of sense operationally, since sites know how to manage those. I really like that idea, especially to keep things simple for the initial system instance rollout.

[garlick]

One slightly unfortunate thing about using supplementary groups is that it might be a bit slow to look them up each time a user connects. OTOH, a cache could always be added later like @dun's:

https://github.com/dun/munge/blob/master/src/munged/gids.c

[grondo]

Yeah, I was thinking we could copy the approach used in MUNGE

[dun]

FYI, gids.c is GPLv3+ which is incompatible with the LGPL3 used by Flux -- well, unless you want Flux to become GPLv3. But, at least, you can see the scalability issues I've had to address for sites with large numbers of users & groups.

[garlick]

That is a fun one :-)

I think actually our problem is somewhat constrained compared to munge. We won't need to fetch a users's entire supplemental group list, rather just test whether or not they are members of a short configured list of groups.