system_views

Представление системного спейса (или 'sysview') — копия системного спейса с доступом только для чтения.

Представления системных спейсов и соответствующие им системные спейсы:
_vcollation — представление _collation,
_vfunc — представление _func,
_vindex — представление _index,
_vpriv — представление _priv,
_vsequence — представление _sequence,
_vspace — представление _space,
_vspace_sequence — представление _space_sequence,
_vuser — представление _user.

Структура кортежей в представлении системного спейса идентична структуре кортежам соответствующего спейса. Однако права там обычно отличаются. По умолчанию у обычных пользователей в большинстве системных спейсов нет никаких прав, однако в представлениях системных спейсов у них есть право чтения.

Ситуация по умолчанию:

• У роли 'public' есть право 'read' во всех представлениях системных спейсов, потому что именно так обстоят дела при создании базы данных.
• У всех пользователей есть роль 'public', потому что она назначается им автоматически при выполнении box.schema.user.create().
• В представлении системного спейса будут содержаться кортежи соответствующего системного спейса, только если у пользователя есть право, связанное с объектом, упомянутом в кортеже.
  Как результат, если администраторы не изменят права, у остальных пользователей не будет доступа к системному спейсу, но будет доступ к представлению системного спейса, где видны только доступные им объекты.

Например, пользователь 'admin' обычно имеет полный доступ к спейсу _space, поэтому и _vspace для него выглядит как _space. А 'guest' имеет только право на чтение _vspace, так что _vspace для него содержит меньше кортежей, чем _space. Поэтому в большинстве систем пользователю 'guest' чтобы получить список спейсов, следует делать выборку из _vspace.

Пример

В этом примере рассмотрим разницу между _vuser и _user. Представление _vuser содержит только кортежи, которые доступны текущему пользователю. Если же у пользователя есть полный набор прав (как у пользователя 'admin'), то содержимое _vuser совпадает с содержимым _user.

Чтобы посмотреть, как работает _vuser, подключитесь к базе данных Tarantool удаленно через net.box и выберите все кортежи из спейса _user — как при наличии, так и при отсутствии у пользователя 'guest' права на чтение из базы данных.

Запустите Tarantool и назначьте права read, write и execute пользователю guest:

 
tarantool> box.cfg{listen = 3301}---...tarantool> box.schema.user.grant('guest', 'read,write,execute', 'universe')---...

Переключитесь на другой терминал, подключитесь к экземпляру Tarantool и выберите все кортежи из спейса _user:

 
tarantool> conn = require('net.box').connect(3301)---...tarantool> conn.space._user:select{}---- - [0, 1, 'guest', 'user', {}]  - [1, 1, 'admin', 'user', {}]  - [2, 1, 'public', 'role', {}]  - [3, 1, 'replication', 'role', {}]  - [31, 1, 'super', 'role', {}]...

Будут показаны те же пользователи, как если бы вы отправили запрос из своего экземпляра Tarantool как 'admin'.

Переключитесь на первый терминал и отзовите право read у пользователя 'guest':

 
tarantool> box.schema.user.revoke('guest', 'read', 'universe')---...

Переключитесь на другой терминал, остановите сессию (чтобы остановить tarantool, нажмите Ctrl+C или Ctrl+D), запустите и подключитесь снова, а затем повторите запрос conn.space._user:select{}. Доступ будет запрещен:

 
tarantool> conn.space._user:select{}---- error: Read access to space '_user' is denied for user 'guest'...

Однако если вместо этого сделать select из _vuser, появятся данные пользователей, доступные пользователю 'guest':

 
tarantool> conn.space._vuser:select{}---- - [0, 1, 'guest', 'user', {}]...