There are a number of idents, both users and groups. All ident names have a
MIMER_prefix and group idents have a
_GROUPsuffix to aid with their identification.
The user ident
MIMER_ADMcan be thought of as an administrator, which is the reason why the user has been given the system privilege to create new idents and tables. Access and object privileges are not granted directly to the user but inherited through membership of
MIMER_ADMIN_GROUP. This group of idents has a high level of privileges to manipulate the database tables and views but they do not have total uncontrolled access, only the
MIMER_STOREident has that. It should be possible to perform a lot of the course work from the
MIMER_USRis granted membership of the
MIMER_STORE_GROUP. As can be seen it is possible to grant a group membership of another group; in this case, the members of the
MIMER_ADMIN_GROUP(now and in the future) are automatically granted whatever privileges are allocated to
MIMER_STORE_GROUP. So when the execute privilege on the PSM procedure
COMING_SOONis allocated to
MIMER_STORE_GROUPit is automatically also granted to the members of
MIMER_ADMIN_GROUP, which includes the user
Note: At the end of the default installation of the example database, the permission to create further idents and databanks from example environment is revoked. This is since the default system is given official passwords, and therefore is open to any user. The revoke commands used are the following:REVOKE DATABANK FROM MIMER_STORE; REVOKE IDENT FROM MIMER_STORE CASCADE;
To deliberately open up the system, use the GRANT IDENT and GRANT DATABANK statements.
See the exdef.sql file for details.
Mimer Information Technology AB
Voice: +46 18 780 92 00
Fax: +46 18 780 92 40