Config option to disable user management

[Gerold103]

The patch introduces a new option schema_management_mode which allows to turn off automatic access management (users, grants, function exports). It also adds helper functions for exports deploy.

Closes #435.

[Gerold103]

@ImeevMA can you please have a look and check if this is enough for config module? You can now disable the user management. But I still do func.create() for various internal functions, since they don't seem to be related to users. Let me know if those also shouldn't be created (but then you would need to grant execute universe rights to your manual user or create those functions yourself in the same way - both sound like bad ideas).

[ImeevMA]

@Gerold103 Regarding function creation and granting of privileges, the plan is to introduce granting of privileges for Lua functions not from _func. We then plan to introduce a new default role, sharding, which will have execute access to all necessary Lua vshard functions. So, in order for the user to perform these functions, we just need to give him this role. I believe this would solve all the problems with creating functions and granting privileges. How do you think?

The only problem is that we don't know when exactly this feature will arrive. Anyway, it looks like we can disable function creation and privilege granting in vshard. If the feature comes too late, we'll come up with something on our end.

@Totktonada, do you have anything to add?

[Totktonada]

I think that it would be good to control whether to add _func entries. This ability doesn't look critical for our tasks, but it would be more clean to don't add the entries if they're not needed.

More on it: how about exposing a function list that are essential to expose into iproto to make rebalancer and router working? If we have a declarative information about vshard functions in the config logic, we can better support different vshard versions.

[Totktonada]

NB: Current version of the in-progress RFC regarding granular lua_call privilege discards access to a function according to the lua_call privilege if it is present in _func. It means that we need to control whether box.schema.func.create() will be called.

[Totktonada]

NB 2: @locker agreed to allow lua_call if a _func entry is present (in some cases). It is tracked by https://github.com/tarantool/tarantool/issues/9363.

Anyway, I think that control, whether to create _func entries in vshard, is a good feature.

[Gerold103]

@Totktonada will this Lua grants feature allow to grant access to not yet created functions? It is not needed right now, but in future it might become necessary, if vshard storages would want to communicate with each other during first vshard.storage.cfg. Then I would need the grants to be present before the first cfg, thus before those functions are properly created. (Before the first cfg there are stubs, but they only throw an error.)

[locker]

will this Lua grants feature allow to grant access to not yet created functions?

Yes, they will (see the design document).

[Totktonada]

However, they're still stored in _priv, so not accessible before first box.cfg().

[Gerold103]

@Totktonada and @ImeevMA , please, check the new version out.

• You can disable user, functions, and grants management via schema_management_mode = 'manual_access' config option;
• You can deploy those things yourself using the new module vshard.storage.exports. The field exports.log contains the history of versions. Once you've found the one you want, you can compile them for the current core version and then deploy functions and/or grants:

  local lvexports = require('vshard.storage.exports')
  local exports = find_exports_for_vshard_version(lvexports.log, vshard_version_str)
  exports = lvexports.compile(exports)
  lvexports.deploy_funcs(exports)
  lvexports.deploy_privs(exports, username_to_grant_privs_to)

[Totktonada]

@Gerold103 It seems that it is conceptually what we need.