Ban creating keyring encrypted tables inside Master Key encrypted tablespaces and vice versa:

• it should not be possible to create a keyring encrypted table inside a Master Key encrypted tablespace and the other way around.

• it should not be possible to move keyring encrypted table into Master Key encrypted tablespace (i.e. ALTER TABLE t TABLESPACE=ts_mk; where t is KEYRING encrypted and ts_mk is Master Key encrypted), and the other way around.

It should be possible to create an encrypted table inside a database with DEFAULT ENCRYPTION=’Y’. In particular it should be possible to create keyring encrypted tables inside such database without TABLE_ENCRYPTION_ADMIN privileges.

It should be also possible to move Keyring encrypted tables into such database (either with RENAME or ALTER TABLE RENAME statement).

When default_table_encryption is set to ONLINE_TO_KEYRING the value inherited by DEFAULT ENCRYPTION is ‘N’. Since this is not explicit ‘N’ the tables created inside such database will not be excluded from encryption threads by default.

When default_table_encryption is set to ONLINE_TO_KEYRING newly created tables are encrypted “in background” encryption mode. Those tables can be decrypted by encryption threads.

The same behavior follows for tablespaces.

default_table_encryption=ONLINE_TO_KEYRING will override TABLE_ENCRYPTION_ADMIN privileges, in the sense that ONLINE_KEYRING encrypted tables will be created in databases regardless of DEFAULT_ENCRYPTION setting (it could be either Y or N).

if table is online_keyring encrypted we skip checks for TABLE_ADMIN_ENCRYPTION. Even if d_t_e=ONLINE_TO_KEYRING was disabled.

After implementing : Intoduce crypt_schema 2 for better error checking in encryption, check that scenarios for: CREATE TABLE t1(a INT) ENCRYPTION='N/Y/KEYRING' TABLESPACE=ts1 where ts1 is tablespace with keyring encryption in progress are covered.