Представления системных спейсов
Представление системного спейса (или „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
.
To see how _vuser
works,
connect to a Tarantool database remotely
via net.box
and select all tuples from the _user
space, both when the „guest“ user is and is not allowed to read from the
database.
Запустите 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', {}]
...