Une petite histoire addictive avec les permissions du répertoire spécifié par expdp (pour les débutants)

Bonjour. Mon nom est hrkii123.

Cette entrée est l'article du 18e jour du calendrier de l'Avent JPOUG 2019.

Le premier message de Qiita est le Calendrier de l'Avent JPOUG 2019.

Calendrier de l'Avent JPOUG 2019 https://adventar.org/calendars/4154

introduction

Cette fois, je suis accro à l'utilitaire expdp de datapump.

Un jour. Nous avons conçu autour de la base de données avec l'exigence que les utilisateurs du système d'exploitation, les utilisateurs de la base de données, les répertoires du système d'exploitation, etc. soient séparés pour chaque équipe de développement afin que les données ne puissent pas être référencées les unes par rapport aux autres. Parmi eux, une commande a été passée pour préparer un répertoire OS à exporter par datapump pour chaque équipe afin qu'elles ne puissent pas se référer aux fichiers de vidage de l'autre.

Je pensais que ce serait facile à contrôler avec les autorisations d'un tel répertoire OS. (Ce n'était pas si facile.)

J'ai donc résumé le contenu de vérification que j'ai essayé de différentes manières.

Diagramme schématique

Exportez le schéma user_A vers / var / work / Adir avec datapump. Après l'exportation, seuls les utilisateurs Aadmin peuvent accéder aux fichiers de vidage sous / var / work / Adir, et les utilisateurs Badmin ne peuvent pas y accéder. L'accès est possible en définissant les autorisations du répertoire OS. En outre, bien que non illustré sur la figure, la base de données a utilisé l'environnement 12.1 RAC. (Parce que j'avais une machine virtuelle ..)

無題のプレゼンテーション (3).png

Créez un utilisateur DB "user_A" et un objet d'annuaire "dirA" pour vérification. Accordez les privilèges nécessaires à l'utilisateur de base de données "user_A".

create user user_A identified by welcome1;
CREATE DIRECTORY dirA AS '/var/work/Adir';
grant create session,resource,unlimited tablespace to user_A;
grant read, write on directory dirA to user_A;

Maintenant, expdp peut-il être exécuté dans cet état?

/u01/app/oracle/product/12.1.0/dbhome_1/bin/expdp user_A/welcome1@testdb directory=dirA dumpfile=expdp_A.log schemas=user_A

Une erreur s'est produite comme indiqué dans la sortie ci-dessous.

ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 536
ORA-29283: invalid file operation

L'erreur ci-dessus est générée lorsque les autorisations du répertoire du système d'exploitation ne sont pas appropriées.

Le répertoire OS spécifié dans l'objet d'annuaire est le propriétaire Aadmin et le propre groupe Aadmin. Les fichiers de vidage exportés par les spécifications de la pompe de données appartiennent à oracle et appartiennent à asmadmin. En d'autres termes, pour exécuter le vidage de données, il est nécessaire d'autoriser l'accès de l'utilisateur oracle et du groupe asmadmin. Si les autorisations du répertoire du système d'exploitation sont 777, vous n'avez à vous soucier de rien, mais dans ce cas, l'utilisateur oracle n'appartient pas au groupe Aadmin, vous ne pouvez donc pas accéder au répertoire du système d'exploitation.

Pour contourner ce problème, nous ajouterons cette fois Aadmin aux groupes secondaires d'utilisateurs oracle et grid.

id oracle
uid=54321(oracle) gid=54321(oinstall)groups=54321(oinstall),54322(dba),1101(oper),1102(backupdba),1103(dgdba),1104(kmdba),1201(asmdba),54323(Aadmin)

id grid
uid=1100(grid) gid=54321(oinstall)groups=54321(oinstall),1200(asmadmin),1201(asmdba),1202(asmoper),54323(Aadmin)

Va-t-il réussir cette fois?

ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 536
ORA-29283: invalid file operation

Il est ressorti à nouveau. Cette erreur! !! Je devrais pouvoir accéder au répertoire OS,

À propos, si vous modifiez l'autorisation du répertoire du système d'exploitation en 777, cela fonctionne normalement.

$ /u01/app/oracle/product/12.1.0/dbhome_1/bin/expdp user_A/welcome1@testdb directory=dirA 
dumpfile=expdp_A.log schemas=user_A

Export: Release 12.1.0.2.0 - Production on Sun Dec 15 03:53:01 2019

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
Starting "USER_A"."SYS_EXPORT_SCHEMA_01":  user_A/********@testdb directory=dirA dumpfile=expdp_A.log schemas=user_A
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Master table "USER_A"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for USER_A.SYS_EXPORT_SCHEMA_01 is:
  /var/work/Adir/expdp_A.log
Job "USER_A"."SYS_EXPORT_SCHEMA_01" successfully completed at Sun Dec 15 03:53:42 2019 elapsed 0 00:00:38

[oracle@node1 ~]$

Comment as-tu fait ça après tout

Lors de l'ajout d'un groupe secondaire d'utilisateurs oracle, grid dans un environnement RAC, il est nécessaire de rendre le clusterware conscient! Il sera reconnu en redémarrant le clusterware après avoir ajouté le groupe. Vous pouvez vérifier si le clusterware est conscient qu'un groupe d'utilisateurs a été ajouté en vérifiant le processus pmon.

Après avoir redémarré CRS

ps -ef | grep pmon
    grid     14417     1  0 05:37 ?        00:00:00 asm_pmon_+ASM1
    oracle   15136     1  0 05:37 ?        00:00:00 ora_pmon_ctestdb1
    grid     15143     1  0 05:37 ?        00:00:00 mdb_pmon_-MGMTDB
    oracle   30528 27106  0 06:06 pts/1    00:00:00 grep pmon

cat /proc/14417/status |grep Groups

Groupes: 1200 1201 1202 54321 54323 ★ 54323 (Aadmin) est reconnu

cat /proc/15136/status |grep Groups

Groupes: 1101 1102 1103 1104 1201 54321 54322 54323 ★ 54323 (Aadmin) est reconnu

Maintenant expdp est enfin possible.

$ /u01/app/oracle/product/12.1.0/dbhome_1/bin/expdp user_A/welcome1@testdb directory=dirA dumpfile=expdp_A.log schemas=user_A

Export: Release 12.1.0.2.0 - Production on Sun Dec 15 05:58:12 2019

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
Starting "USER_A"."SYS_EXPORT_SCHEMA_01":  user_A/********@testdb directory=dirA dumpfile=expdp_A.log schemas=user_A
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Master table "USER_A"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for USER_A.SYS_EXPORT_SCHEMA_01 is:
  /var/work/Adir/expdp_A.log
Job "USER_A"."SYS_EXPORT_SCHEMA_01" successfully completed at Sun Dec 15 05:58:36 2019 elapsed 0 00:00:23

Nous avons également un contrôle d'accès que nous voulions réaliser.

$ id
uid=54323(Badmin) gid=54324(Badmin) groups=54324(Badmin)
$ cd /var/work/Adir/
-bash: cd: /var/work/Adir/: Permission denied
$ ls -l /var/work/Adir/
ls: cannot open directory /var/work/Adir/: Permission denied

C'est tout.

Restez à l'écoute pour l'article sur le 19ème jour du Calendrier de l'Avent JPOUG 2019 ~