-
At the later stage I discovered that sbroad applies the same validation rules during parsing of grant/revoke statements and even its own Privilege enum that is a ~copy of our PrivilegeType. Unfortunately at the moment there is no way to share code between picodata and sbroad efficiently (now only tarantool-module is shared and it is not suitable for such kind of things) so it still makes sense to have this in picodata because this is the point where all APIs converge to the single point (CaS). In the future all other ways of validation should be removed. Aside from sbroad similar kind of validation is performed independently on lua API side. Note that in prior commit 45ba7392 we've removed all privileges from role super. This patch removes privileges from admin that do not match the model: namely all privileges on universe except session and usage. With this patch it is no longer possible to grant or revoke such privileges.
At the later stage I discovered that sbroad applies the same validation rules during parsing of grant/revoke statements and even its own Privilege enum that is a ~copy of our PrivilegeType. Unfortunately at the moment there is no way to share code between picodata and sbroad efficiently (now only tarantool-module is shared and it is not suitable for such kind of things) so it still makes sense to have this in picodata because this is the point where all APIs converge to the single point (CaS). In the future all other ways of validation should be removed. Aside from sbroad similar kind of validation is performed independently on lua API side. Note that in prior commit 45ba7392 we've removed all privileges from role super. This patch removes privileges from admin that do not match the model: namely all privileges on universe except session and usage. With this patch it is no longer possible to grant or revoke such privileges.
