Discussion :

[davidsil]

Bonjour à tous,

Nous rencontrons un problème avec l’erreur suivante : ORA-01031: privilèges insuffisants

Nous utilisons une base Oracle 10.

Nous avons créé une API en .NET 4.7 qui interroge une base Oracle 10.
Dans cette base Oracle 10, nous avons créé 2 vues

A ce jour, notre API effectue les requêtes suivantes :

1) Interrogation d’une table pour récupérer les informations de connexion (email, mot de passe)
2) Interrogation de 2 vues.

De manière aléatoire, lorsque notre API interroge les vues, nous obtenons le message suivant : ORA-01031: privilèges insuffisants
A partir du premier message d’erreur, nous n’arrivons plus à questionner nos vues car les privilèges sont insuffisants.

Nous n’arrivons aps à déterminer la cause et ce qui est vraiment étrange, c’est que le cas se produit de manière aléatoire !

Nous devons rebooter le pool d’application d’IIS pour ne plus rencontrer le problème.

L’utilisateur utilisé pour se connecter à la base est un utilisateur qui a tous les droits.

Une idée ?

Merci pour vos retours.

Bonne journée.

[Ikebukuro]

Est-ce que les droits ont été donnés sur ces vues en direct ou via un rôle à ce user?
Si vous êtes passés par un rôle, donnez les droits en direct avec un GRANT et retestez.

Sur quoi pointent ces vues : sur les tables d'un seul schéma, sur plusieurs schémas, sur un schéma différent de celui du user qui veut faire un SELECT...
Ce serait bien d'avoir la définition de ces vues car les pbs de droits peuvent venir du fait que les vues pointent vers un autre schéma.

Ah, dernière remarque, même si le user a tous les droits, genre SYSTEM, il a parfois des limites, notamment dès qu'on parle de rôles, vues, procédures stockées...

[davidsil]

Merci de ta réponse.

> Est-ce que les droits ont été donnés sur ces vues en direct ou via un rôle à ce user?

Non le user a le droit de lire tout. Sur SQLPlus l'accès a ces vues ne pose aucun problème.

> Si vous êtes passés par un rôle, donnez les droits en direct avec un GRANT et retestez.

Je vais tenter l'ajout d'un grant particulier mais comme précisé plus haut avec SQLPlus tout marche.

> Sur quoi pointent ces vues : sur les tables d'un seul schéma, sur plusieurs schémas, sur un schéma différent de celui du user qui veut faire un SELECT...
> Ce serait bien d'avoir la définition de ces vues car les pbs de droits peuvent venir du fait que les vues pointent vers un autre schéma.

Les vues pointent sur des tables du même schema que la vue (donc un seul schema au total). Ensuite c'est vrai qu'une des vue utilise une fonction.

> Ah, dernière remarque, même si le user a tous les droits, genre SYSTEM, il a parfois des limites, notamment dès qu'on parle de rôles, vues, procédures stockées...

Le souci c'est que le problème n'arrive pas tout le temps donc c'est assez chaud à tester mais en effet comme la vue utilise des fonctions peut être y a-t-il un lien.

[Ikebukuro]

Si je comprends bien, sous SQL*Plus il n'y a aucun problème mais c'est en passant par votre API qu'il y a un souci?

Si c'est bien le cas, le pb n'est pas sous Oracle (enfin, ce n'est pas un pb de droits ou autre).

Est-ce que vous utilisez TOUJOURS le même user Oracle quand vous utilisez l'API? Quand vous dites que l'erreur arrive de manière aléatoire, vous avez identifié des différences dans les lancements de votre API?
Je vous conseille de vous focaliser sur l'environnement de votre API, sur comment elle est appelée car si tout est OK en full Oracle (SQL*Plus et accès aux vues), alors le pb est lié à l'API et là je ne peux plus vous aider.

[McM]

Si une des fonctions utilise un procédure SYS dans un cas particulier, et que le droit d'exécution n'a pas été spécifiquement donné à l'utilisateur qui fait un query sur la vue, tu peux te retrouver avec cette erreur.
Faut vérifier en détail le code des fonctions.

Le mieux serait d'arriver à reproduire le cas, mais si c'est vraiment aléatoire, alors bonne recherche

[davidsil]

Bonjour,

merci pour le retour.

Notre lead dev s'occupe de changer d’environnement.

Par contre, je suis assez surpris. Même si c'est un problème lié à l’environnement, au final, je me retrouve quand même avec une erreur liée aux privilèges de la BDD.

Egalement, plusieurs utilisateurs accèdent à la base de données via l'API.

A-t-on la possibilité via un script ou une ligne de commande, avant chaque appel sur la vue, de consulter l'utilisateur, sa connexion à la BDD et les privilèges associés ?
Avant et après l’exécution de la requête.

Egalement, a-t-on la possibilité d'executer un grant ou un SQL qui permettrait de générer des droits sur tout (sur les tables, les vues, les fonctions...). Pour éviter de se poser la question des droits.

J'aimerai déjà écarter ce problème de droits avant tout chose.

En tous cas merci pour votre aide. Nous sommes vraiment dans l'inconnu. :-)

[Ikebukuro]

A-t-on la possibilité via un script ou une ligne de commande, avant chaque appel sur la vue, de consulter l'utilisateur, sa connexion à la BDD et les privilèges associés ?
Avant et après l’exécution de la requête.

Pour ça, il faudra mettre en place un audit Oracle sur cette vue. Le lien suivant me semble un peu succinct mais ils utilisent l'audit de granularité fine FGA qui est intéressant à connaître.
http://www.orafaq.com/wiki/DBMS_FGA

[davidsil]

Merci pour votre retour.

Nous allons tester.

J'ai vu ce genre de requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GRANT SELECT ON [TABLE_NAME] TO [READ_USERNAME] WITH GRANT OPTION;

Ne serait-ce pas utile ?

l'idée est d'écarter le problème de droits dans un premier temps. Si tout est ok, on étudiera les droits spécifiquement si besoin.

[Ikebukuro]

Cela fait un petit bout de temps que je n'ai pas testé les multiples aspects des droits sous oracle et, étant au boulot, je peux pas faire n'importe quoi.
Néanmoins, de mémoire, si un user A veut faire un SELECT sur une vue du user B qui pointe sur une table du user B, je crois qu'il faut donner au user A les droits sur la vue et sur la table du user B donc ton GRANT me semble un peu faible.
En outre le WITH GRANT OPTION n'a pas d'intérêt dans ton cas car il permet juste à un user de donner le même droit à un autre user.

[Fabien Celaia]

Ne serait-ce pas plutôt WITH ADMIN OPTION ?

[Ikebukuro]

"WITH GRANT OPTION" pour les privilèges objets mais "WITH ADMIN OPTION" pour les privilèges systèmes.

[davidsil]

Merci ! :-)

Nous avons changé l'environnement et nous avons la même erreur.

Est-il possible de savoir la cause de cette erreur de privilèges ? J'en doute mais ca serait top !

Sinon, j'ai consulté les droits sous oracle :

Effectivement, on va éviter with admin option et with grant option. En terme de sécurité ce n'est pas top.


Je continue de regarder au niveau des droits.

[IndianaAngus]

Pour ça, il faudra mettre en place un audit Oracle sur cette vue. Le lien suivant me semble un peu succinct mais ils utilisent l'audit de granularité fine FGA qui est intéressant à connaître.
http://www.orafaq.com/wiki/DBMS_FGA

attention, pour utiliser FGA il faut l'option Advanced Security. Par contre vous pouvez utiliser l'audit standard.

[Ikebukuro]

attention, pour utiliser FGA il faut l'option Advanced Security. Par contre vous pouvez utiliser l'audit standard.

Es-tu sur de cela? Sur une doc Oracle ils parlent des features "Transparent Data Encryption and Redaction" mais pas de FGA dans ce pack.

[davidsil]

Es-tu sur de cela? Sur une doc Oracle ils parlent des features "Transparent Data Encryption and Redaction" mais pas de FGA dans ce pack.

Bonjour à tous,

Merci pour vos retours.

Nous avons résolu le problème en changeant d’environnement. Il semblerait que notre API ne tapait pas sur la base avec le bon user (même si nous n'avons pas su isolé le problème)

Nous avons mis en place Dapper et depuis plus de problème.

Merci à tous.

je ne sais pas si je dois mettre le sujet en résolu.

Bonne conituation