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