Comment reconnaitre un bon Linuxien d'un vrai neuneu ?

Stephane TOUGARD

27/07/2005 à 03:34

helios wrote:

un SGBD autre se connect sous un compte linux et connect apres en interne
ses propres users donc le crack du sgbd donne acces atout les users du sgbd

Et la marmotte, elle referme l'aluminium autour du chocolat.

--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License

Stephane TOUGARD

27/07/2005 à 03:35

helios wrote:

la secretaire est la pour faire des stats et l'outil SQL ne lui permet pas
de faire des stat non prevu par les informaticiens donc ....
alors qu'avec pick elle fait les stat qu'elle veux sans passer pour un
bovidé

Avec 10 ans d'experiences dans l'informatique, je passerai pour un
bovide devant un tel truc. Alors la secretaire, va deja falloir lui
apprendre a utiliser ssh.

Tiens d'ailleurs, pick, ca supporte ssh ?

--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License

Stephane TOUGARD

27/07/2005 à 03:36

Jérémy JUST wrote:

On voit couramment des bases à 60-80 tables, quand on travaille
sur des données réelles. Il doit être assez facile de trouver
plus compliqué, par exemple quand deux bases ont été fusionnées après
leurs conceptions indépendantes.

Lorsque j'avais fait un logiciel de billing sous PostgreSQL, on etait a
120 tables, c'est faible pour ce type d'applis.

--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License

Franck Yvonnet

27/07/2005 à 06:38

Ainsi Parlait helios

sous pick l'administrateur system est aussi l'administrateur BDD
interet la securite sous un BDD autre pick il suffit de crak un utilisateur
pour avoir acces a toute la base tandis que sous pick le crack d'un user
donne acces a l'user rien d'autre

Faux. Sous SQL tu peux restreindre les privilièges d'un utilisateurs
(avec grant et revoke), et même si tu te connectes au compte d'un
utilisateur de façon illégitime (par exemple par SQL injection dans une
appli codée avec les pieds) tu n'as de toute façon accès qu'aux données
autorisées par cet utilisateur. Et ça n'a rien à voir avec le fait que
le DA soit admin système ou non.

--
Franck Yvonnet
I remember when trolls were fairy tale creatures who lived under bridges.
Now homeless people live there and trolls live on Usenet.

Franck Yvonnet

27/07/2005 à 06:41

Ainsi Parlait helios

seulemnt une fois oracle plante il y a plus de separation entre les
utilisateurs puisque le system ne sait pas separer tandis que sosu pick meme
avec pick planter le system continu de separer les utilisateurs

Si la base de données est plantée, il n'y a plus d'accès aux données,
donc quel intérêt qu'il y ait encore une notion d'utilisateurs ?

--
Franck Yvonnet
I remember when trolls were fairy tale creatures who lived under bridges.
Now homeless people live there and trolls live on Usenet.

Vincent Bernat

27/07/2005 à 07:15

OoO En cette nuit striée d'éclairs du mercredi 27 juillet 2005, vers
02:13, Stephane TOUGARD disait:

donc les mec de FT ont un probleme de competence oracle et pourtant d'apres
d'autre source c'est FT qui a la plus grosse base oracle du monde et FT
traite directement avec oracle , ibm

Quelles sources ?

On devrait trouver ça sous peu sur le site de référence www.com02.com.
--
printk(KERN_WARNING "%s: Short circuit detected on the loben",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c

Richard Delorme

27/07/2005 à 07:50

Et la marmotte, elle referme l'aluminium autour du chocolat.

La publicité correspondante n'étant plus diffusée depuis longtemps, je
trouve cette allusion ringarde...

--
Richard

Vincent Bernat

27/07/2005 à 07:59

OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 26 juillet
2005, vers 23:23, Yannick Patois disait:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Ah, il fait de la séparation de privilèges ! Déjà, je pense que si
c'était le cas, il nous l'aurait dit directement (il est admin
Unix). Tu lui fabriques juste une explication claire et plausible.

Maintenant, n'oublions pas que :
- Pick est portable, donc doit fonctionner sur les systèmes dont le
système de fichiers a des droits rudimentaires (pas d'ACL). Si on
veut autoriser les commerciaux à rajouter des factures, à les
consulter mais à ne pas les supprimer, au niveau du système de
fichiers, on se retrouve avec des droits en écriture pour tout le
monde. Sur un SGBDR, toutes les tables ont des droits spécifiques
selon l'opération, voire la colonne. Si le système de fichiers doit
faire tout le boulot (chaque facture est un fichier dans un
répertoire en +t), il n'y a plus de base de données. Bref, il me
semble hautement improbable que Pick se repose sur les privilèges
du système pour faire tout ça pour cette raison.
- Pick exploite directement des raw devices. Je connais peu de
systèmes assurant la granularité des droits à l'intérieur d'un tel
bidule (voire aucun). Deuxième raison de penser qu'il n'y a pas une
telle séparation de privilèges.
- Pick travaille au niveau 0 (sic), ce qu'un processus utilisateur ne
peut pas faire, quel que soit la réalité du niveau 0. Il n'y a pas
de problèmes particuliers de performance à demander un login et un
mot de passe. Il me smeble donc plus réaliste que ce soit le
système Pick en lui même et non le processus non privilégié qui
gère les accès à la base dans ce cas.

En bref, tout ce qui est avancé sur Pick se contredit mutuellement. Il
me semble plus simple de dire que l'intervenant sait gérer une base
Pick et qu'il ne fait que ça. Il n'a aucune notion de sécu,
d'administration système ou autres et il nous invente tout. On parlé
sécu, le bidule est méga cloisonné. On parle perf et hop, tout se
retrouve au "niveau 0".
--
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c

OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 26 juillet
2005, vers 23:23, Yannick Patois <patois@calvix.org> disait:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Ah, il fait de la séparation de privilèges ! Déjà, je pense que si
c'était le cas, il nous l'aurait dit directement (il est admin
Unix). Tu lui fabriques juste une explication claire et plausible.

Maintenant, n'oublions pas que :
- Pick est portable, donc doit fonctionner sur les systèmes dont le
système de fichiers a des droits rudimentaires (pas d'ACL). Si on
veut autoriser les commerciaux à rajouter des factures, à les
consulter mais à ne pas les supprimer, au niveau du système de
fichiers, on se retrouve avec des droits en écriture pour tout le
monde. Sur un SGBDR, toutes les tables ont des droits spécifiques
selon l'opération, voire la colonne. Si le système de fichiers doit
faire tout le boulot (chaque facture est un fichier dans un
répertoire en +t), il n'y a plus de base de données. Bref, il me
semble hautement improbable que Pick se repose sur les privilèges
du système pour faire tout ça pour cette raison.
- Pick exploite directement des raw devices. Je connais peu de
systèmes assurant la granularité des droits à l'intérieur d'un tel
bidule (voire aucun). Deuxième raison de penser qu'il n'y a pas une
telle séparation de privilèges.
- Pick travaille au niveau 0 (sic), ce qu'un processus utilisateur ne
peut pas faire, quel que soit la réalité du niveau 0. Il n'y a pas
de problèmes particuliers de performance à demander un login et un
mot de passe. Il me smeble donc plus réaliste que ce soit le
système Pick en lui même et non le processus non privilégié qui
gère les accès à la base dans ce cas.

En bref, tout ce qui est avancé sur Pick se contredit mutuellement. Il
me semble plus simple de dire que l'intervenant sait gérer une base
Pick et qu'il ne fait que ça. Il n'a aucune notion de sécu,
d'administration système ou autres et il nous invente tout. On parlé
sécu, le bidule est méga cloisonné. On parle perf et hop, tout se
retrouve au "niveau 0".
--
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c

Vous avez filtré cet utilisateur ! Consultez son message

OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 26 juillet
2005, vers 23:23, Yannick Patois disait:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Ah, il fait de la séparation de privilèges ! Déjà, je pense que si
c'était le cas, il nous l'aurait dit directement (il est admin
Unix). Tu lui fabriques juste une explication claire et plausible.

Maintenant, n'oublions pas que :
- Pick est portable, donc doit fonctionner sur les systèmes dont le
système de fichiers a des droits rudimentaires (pas d'ACL). Si on
veut autoriser les commerciaux à rajouter des factures, à les
consulter mais à ne pas les supprimer, au niveau du système de
fichiers, on se retrouve avec des droits en écriture pour tout le
monde. Sur un SGBDR, toutes les tables ont des droits spécifiques
selon l'opération, voire la colonne. Si le système de fichiers doit
faire tout le boulot (chaque facture est un fichier dans un
répertoire en +t), il n'y a plus de base de données. Bref, il me
semble hautement improbable que Pick se repose sur les privilèges
du système pour faire tout ça pour cette raison.
- Pick exploite directement des raw devices. Je connais peu de
systèmes assurant la granularité des droits à l'intérieur d'un tel
bidule (voire aucun). Deuxième raison de penser qu'il n'y a pas une
telle séparation de privilèges.
- Pick travaille au niveau 0 (sic), ce qu'un processus utilisateur ne
peut pas faire, quel que soit la réalité du niveau 0. Il n'y a pas
de problèmes particuliers de performance à demander un login et un
mot de passe. Il me smeble donc plus réaliste que ce soit le
système Pick en lui même et non le processus non privilégié qui
gère les accès à la base dans ce cas.

En bref, tout ce qui est avancé sur Pick se contredit mutuellement. Il
me semble plus simple de dire que l'intervenant sait gérer une base
Pick et qu'il ne fait que ça. Il n'a aucune notion de sécu,
d'administration système ou autres et il nous invente tout. On parlé
sécu, le bidule est méga cloisonné. On parle perf et hop, tout se
retrouve au "niveau 0".
--
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c

helios

27/07/2005 à 10:03

"Stephane TOUGARD" a écrit dans le message de
news:

helios wrote:
seulemnt une fois oracle plante il y a plus de separation entre les
utilisateurs puisque le system ne sait pas separer tandis que sosu pick
meme

avec pick planter le system continu de separer les utilisateurs

Ce que tu n'as pas encore compris (mais qu'as tu vraiment compris),
c'est que le fameux plantage dont tu parles, son equivalence sur pick ne
laisse pas l'utilisateur user, mais bel et bien root.

Sauf qu'en plus avec pick, il est root en local, c'est a dire tout,
alors qu'avec un SGBD conventionnel, il est user en distant,
autant dire rien du tout.

Mais surtout, surtout, la grande difference c'est que ta bouse est
prevue pour des utilisateurs connus, donc n'a pas a resister a des
attaques. Par contre, une base MySQL pour un site web est prevu pour des
utilisateurs anonymes, c'est a dire qu'elle doit resister a des attaques
incessantes.

voici la copie du post d'un mec qui a compris

"Yannick Patois" a écrit dans le message de
news:dc69l2$2fph$

Bonjour,

Je vais essayer d'expliquer ce que j'ai crus comprendre du
fonctionnement de pick (auquel je ne connais rien) à travers ce
qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre
vous, d'où des critiques que je juge un peu rapides et infondées.

Le fonctionnement me parait être le suivant:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Que ce soit par un exploit interne à la base (escalade de privilège au
sein de la base) ou d'un exploit permettant de forker un shell, le user
ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une
faille sur le système lui-même).

Par comparaison, une base de donnée mysql (par exemple) tourne sous un
user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les
bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un
exploit interne comme un exploit donnant un shell, permet
potentiellement à un utilisateur de la base de lire et écrire sur
l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes
les bases.

Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.

Bien sur, il faut bien quelque part des utilisateurs privilégiés,
tournant sous des comptes privilégiés, il est même probable que l'admin
de la base doive tourner en root, ou du moins avec un paquet de suids:
ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.

Le plus gros reproche que je vois à ce truc (si j'ai bien compris
comment ca marchait), c'est que c'est très peu portable et très
dépendant du système: par exemple, de nombreux unix ont un UID sur 15
bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on
voudrait plus de 32000 utilisateurs distincts?
De la même façon, utiliser les droits unix pour discriminer des accès
partagés me semble délicat sans ACL; hors de nombreux FS unix ne
disposent pas d'ACL. On fait comment ?

Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de
possible au vue des messages d'helios.

Yannick

PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet
comparable à poster sur fsp: la pénible impression qu'ici toute
discussion rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent ressortir que salit
d'un tel échange...
Je n'avais pas cette impression autrefois.

"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:1jvir2-mq.ln1@gulliver.unices.org...

helios wrote:

seulemnt une fois oracle plante il y a plus de separation entre les
utilisateurs puisque le system ne sait pas separer tandis que sosu pick
meme

avec pick planter le system continu de separer les utilisateurs

Ce que tu n'as pas encore compris (mais qu'as tu vraiment compris),
c'est que le fameux plantage dont tu parles, son equivalence sur pick ne
laisse pas l'utilisateur user, mais bel et bien root.

Sauf qu'en plus avec pick, il est root en local, c'est a dire tout,
alors qu'avec un SGBD conventionnel, il est user en distant,
autant dire rien du tout.

Mais surtout, surtout, la grande difference c'est que ta bouse est
prevue pour des utilisateurs connus, donc n'a pas a resister a des
attaques. Par contre, une base MySQL pour un site web est prevu pour des
utilisateurs anonymes, c'est a dire qu'elle doit resister a des attaques
incessantes.

voici la copie du post d'un mec qui a compris

"Yannick Patois" <patois@calvix.org> a écrit dans le message de
news:dc69l2$2fph$1@biggoron.nerim.net...

Bonjour,

Je vais essayer d'expliquer ce que j'ai crus comprendre du
fonctionnement de pick (auquel je ne connais rien) à travers ce
qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre
vous, d'où des critiques que je juge un peu rapides et infondées.

Le fonctionnement me parait être le suivant:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Que ce soit par un exploit interne à la base (escalade de privilège au
sein de la base) ou d'un exploit permettant de forker un shell, le user
ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une
faille sur le système lui-même).

Par comparaison, une base de donnée mysql (par exemple) tourne sous un
user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les
bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un
exploit interne comme un exploit donnant un shell, permet
potentiellement à un utilisateur de la base de lire et écrire sur
l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes
les bases.

Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.

Bien sur, il faut bien quelque part des utilisateurs privilégiés,
tournant sous des comptes privilégiés, il est même probable que l'admin
de la base doive tourner en root, ou du moins avec un paquet de suids:
ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.

Le plus gros reproche que je vois à ce truc (si j'ai bien compris
comment ca marchait), c'est que c'est très peu portable et très
dépendant du système: par exemple, de nombreux unix ont un UID sur 15
bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on
voudrait plus de 32000 utilisateurs distincts?
De la même façon, utiliser les droits unix pour discriminer des accès
partagés me semble délicat sans ACL; hors de nombreux FS unix ne
disposent pas d'ACL. On fait comment ?

Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de
possible au vue des messages d'helios.

Yannick

PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet
comparable à poster sur fsp: la pénible impression qu'ici toute
discussion rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent ressortir que salit
d'un tel échange...
Je n'avais pas cette impression autrefois.

Vous avez filtré cet utilisateur ! Consultez son message

"Stephane TOUGARD" a écrit dans le message de
news:

helios wrote:
seulemnt une fois oracle plante il y a plus de separation entre les
utilisateurs puisque le system ne sait pas separer tandis que sosu pick
meme

avec pick planter le system continu de separer les utilisateurs

Ce que tu n'as pas encore compris (mais qu'as tu vraiment compris),
c'est que le fameux plantage dont tu parles, son equivalence sur pick ne
laisse pas l'utilisateur user, mais bel et bien root.

Sauf qu'en plus avec pick, il est root en local, c'est a dire tout,
alors qu'avec un SGBD conventionnel, il est user en distant,
autant dire rien du tout.

Mais surtout, surtout, la grande difference c'est que ta bouse est
prevue pour des utilisateurs connus, donc n'a pas a resister a des
attaques. Par contre, une base MySQL pour un site web est prevu pour des
utilisateurs anonymes, c'est a dire qu'elle doit resister a des attaques
incessantes.

voici la copie du post d'un mec qui a compris

"Yannick Patois" a écrit dans le message de
news:dc69l2$2fph$

Bonjour,

Je vais essayer d'expliquer ce que j'ai crus comprendre du
fonctionnement de pick (auquel je ne connais rien) à travers ce
qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre
vous, d'où des critiques que je juge un peu rapides et infondées.

Le fonctionnement me parait être le suivant:

Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.

- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.

- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).

Que ce soit par un exploit interne à la base (escalade de privilège au
sein de la base) ou d'un exploit permettant de forker un shell, le user
ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une
faille sur le système lui-même).

Par comparaison, une base de donnée mysql (par exemple) tourne sous un
user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les
bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un
exploit interne comme un exploit donnant un shell, permet
potentiellement à un utilisateur de la base de lire et écrire sur
l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes
les bases.

Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.

Bien sur, il faut bien quelque part des utilisateurs privilégiés,
tournant sous des comptes privilégiés, il est même probable que l'admin
de la base doive tourner en root, ou du moins avec un paquet de suids:
ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.

Le plus gros reproche que je vois à ce truc (si j'ai bien compris
comment ca marchait), c'est que c'est très peu portable et très
dépendant du système: par exemple, de nombreux unix ont un UID sur 15
bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on
voudrait plus de 32000 utilisateurs distincts?
De la même façon, utiliser les droits unix pour discriminer des accès
partagés me semble délicat sans ACL; hors de nombreux FS unix ne
disposent pas d'ACL. On fait comment ?

Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de
possible au vue des messages d'helios.

Yannick

PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet
comparable à poster sur fsp: la pénible impression qu'ici toute
discussion rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent ressortir que salit
d'un tel échange...
Je n'avais pas cette impression autrefois.

helios

27/07/2005 à 10:10

"Stephane TOUGARD" a écrit dans le message de
news:

helios wrote:
Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.
c'est ce que je me tue a leur expliquer mais il y a pas plus sourd que

celui

qui ne veux pas entendre

Ce qui serait bien, c'est que tu commentes les autres phrases plutot que
celle la seule.

Pour le moment, j'ai plutot l'impression qu'a par faire des requetes
dans pick et juger SQL trop honteux et indigne de toi pour l'apprendre,
tu ne sais en fait pas grand chose de pick.

Comment sont geres la separation des droits et le partages des donnees
dans pick ? ACL ? droits Unix ? protocoles client/serveurs avec
authentifications ? il me semble que le plus incompetants DBA Oracle
sait deja repondre a cela pour la base qu'il gere, hors jusqu'a
maintenant, tu fais du bruit et tu dis que tu pisses plus loin, mais on
a pas encore vu l'ombre d'une goutte.

tout les conducteurs de Dion boutton connaissait la mecanique est ce pour
cela qu'il les conducteur de mercedes doivent connaitre la mecanique
le fonctionnement interne de pick est le probleme de IBM , RAINNINGDATA,
JBASE, ladybridge pas des utilisateurs PICK

un system PICK est un SGBD utilisateur comme les mercedes sont des voiture
pour conducteur
un system SQL est un SGBD pour informaticien comme les Dion Boutton sont des
voiture de mecanicien

donc le fonctionnement interne de pick n'a aucun interet si j'ai un problem
interne j'appel ibm ou un autre comme quand j'ai un probleme avec ma voiture
j'appelle le garagiste

Comment reconnaitre un bon Linuxien d'un vrai neuneu ?

10 réponses

Veuillez sélectionner un problème