Re: How to restrict database to use specific diskgroup within a Grid configuration

From: Sourav Biswas <biswas.sourav_at_hotmail.com>
Date: Fri, 18 Mar 2022 19:00:50 +0000
Message-ID: <OS3P286MB099304154823E9D6540F57A1F0139_at_OS3P286MB0993.JPNP286.PROD.OUTLOOK.COM>



Thanks Martin and Seth.

This came out as a compliance issue, that one DB should not have access to disks of other DBs. The intent is to enforce a restriction, so that any attempt to create data files to ASM diskgroups belonging to other databases should be stopped.

Seth, I have looked into that document about ASM file access control. My current environment has 'oracle' as OS User for all DBs. In order to implement ACL , I have to make dedicated OS User for each DBs and grant them security limits. This is going to be a daunting task, as we have around hundreds of such DBs, if not thousands.

Regards,
Sourav Biswas



From: Seth Miller <sethmiller.sm_at_gmail.com> Sent: Friday, 18 March 2022, 23:18
To: Martin Berger
Cc: biswas.sourav_at_hotmail.com; oracle-l_at_freelists.org Subject: Re: How to restrict database to use specific diskgroup within a Grid configuration

https://docs.oracle.com/en/database/oracle/oracle-database/19/ostmg/asm-access-control-diskgroups.html<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fdatabase%2Foracle%2Foracle-database%2F19%2Fostmg%2Fasm-access-control-diskgroups.html&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=U6wPMCtKInRYhL78MEuuJ0Eb4GOwX0diNipOnpAaqYo%3D&reserved=0>

On Thu, Mar 17, 2022 at 2:21 AM Martin Berger <martin.a.berger_at_gmail.com<mailto:martin.a.berger_at_gmail.com>> wrote: Hi,

I assume you are using Linux and no Exadata or similar. You can assign separate group IDs to the disks of the specific diskgroups and also start the DB instances with different users and group.

If you are using PDBs Path_Prefix and Create_File_Dest can partially help - at least for datafiles.

hth,
 Martin

Am Mi., 16. März 2022 um 20:58 Uhr schrieb Sourav Biswas <biswas.sourav_at_hotmail.com<mailto:biswas.sourav_at_hotmail.com>>: Hello Everyone,

Current environment:

OS: RHEL 7.9
Grid OS User: grid
Grid: 19.14
Oracle OS User: oracle
CDB: 19.14 We are running multiple CDBs with one PDB each, on a single Grid. As per our architecture, for every CDB, we have 3 sets of asm diskgroups(DATA_CDBn,REDO_CDBn,ARCH_CDBn) created.

For example,
CDB1 database will have DATA_CDB1, REDO_CDB1, ARCH_CDB1 diskgroups CDB2 database will have DATA_CDB2, REDO_CDB2, ARCH_CDB2 diskgroup

Since, at ASM level we can see all of the above 6 diskgroups, I would like to introduce some restrictions to every database to read and write to their dedicated diskgroups. I want to ensure that even the sysdba privilege user of a database cannot create datafile on diskgroups belonging to other database.

Please advise how to implement this restriction.

Regards,
Sourav Biswas

--

Martin Berger                Oracle ♠
martin.a.berger_at_gmail.com<mailto:martin.a.berger_at_gmail.com> _at_martinberx<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fmartinberx&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Nj61kapBv7tQbEh%2BhAeRKaOtAzySDnamyRgLxPIln7M%3D&reserved=0>
^∆x      http://berxblog.blogspot.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fberxblog.blogspot.com%2F&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ilIbxTWVaSle%2F8GtxIwWGFOPEYwCT42lFsYx%2BlPMJo4%3D&reserved=0>

--

http://www.freelists.org/webpage/oracle-l Received on Fri Mar 18 2022 - 20:00:50 CET

Original text of this message