Представления системных спейсов

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

The system space views and the system spaces that they are associated with are:
_vcollation, a view of _collation,
_vfunc, a view of _func,
_vindex, a view of _index,
_vpriv, a view of _priv,
_vsequence, a view of _sequence,
_vspace, a view of _space,
_vspace_sequence, a view of _space_sequence,
_vuser, a view of _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', {}]
...