Comment reconnaitre un bon Linuxien d'un vrai neuneu ?
832 réponses
Xandros
Salut,
Depuis les quelques mois que je suis sous Linux et que je fréquente les
Forums dédiés, j'ai pu remarquer une chose.
Il existe 3 types de personnes :
1) Les novices qui viennent du monde Windows et qui posent pleins de
questions sans vraiment chercher les réponses. J'en faisais parti, mais
je me soigne depuis ;)
2) Les neuneux de base, qui n'y connaissent pas grand chose et qui se
défoulent sur le premier novice venu. On les reconnait par leurs
réponses standards : "trop gros - passera pas" - "va chercher sur
Google" - "Prouves le" - "Vas lire MAN ou HOWTO"
En fait, il n'apportent jamais rien au débat, mais font croire qu'ils
s'y connaissent trop pour perdre leur temps avec des novices.
3) Enfin, les "vrais", ceux qui t'apportent LA solution, on les
reconnait par la simplicité de leurs réponses, un lien, une commande,
une solution quoi.
Un grand merci à eux !!!
Tout ça pour dire que le monde Linux serait bien plus simple si la 2eme
cathégorie pouvait simplement admettre qu'ils font parti de la 1er, ou
alors si ils veulent se prétendre de la 3eme, qu'ils apportent de l'aide
ou bien qu'il ferme leurs gue...le.
--
Message envoyé avec ThunderBird
Sous Linux Xandros Deluxe 3.0
ensuite openqm contournant les limites du system d'exploitation il faut qu'il est un acces root
et dans un autre post :
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Qu'il est bon de rire parfois.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
helios wrote:
ensuite openqm contournant les limites du system d'exploitation il faut
qu'il est un acces root
et dans un autre post :
en matiere de securite je vous signale que la securite local d'un centre
de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Qu'il est bon de rire parfois.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
ensuite openqm contournant les limites du system d'exploitation il faut qu'il est un acces root
et dans un autre post :
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Qu'il est bon de rire parfois.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Thierry Thomas
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage Transact-SQL (du style PL/SQL) était exactement le même. Ensuite, ça a dû diverger petit à petit : MS a commencé par virer la portabilité pour que ça ne tourne plus que sur Windows. Je ne sais plus où en est la compatibilité actuellement, mais le protocole d'accès est au moins toujours le même, puisque FreeTDS permet toujours d'accéder aux deux types de bases. Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Parallélement, MS bricolait son moteur Jet, qui n'a rien à voir avec Sybase, et qui le c½ur d'Access. Bizarrement, ils faisaient plus confiance à Jet qu'à Sybase puisque c'est ça qui était utilisé pour stocker les données dans Exchange (leur erzatz de Lotus Notes). -- Th. Thomas.
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version
10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Transact-SQL (du style PL/SQL) était exactement le même. Ensuite, ça a
dû diverger petit à petit : MS a commencé par virer la portabilité pour
que ça ne tourne plus que sur Windows. Je ne sais plus où en est la
compatibilité actuellement, mais le protocole d'accès est au moins
toujours le même, puisque FreeTDS permet toujours d'accéder aux deux
types de bases.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à
Oracle...
Parallélement, MS bricolait son moteur Jet, qui n'a rien à voir avec
Sybase, et qui le c½ur d'Access. Bizarrement, ils faisaient plus
confiance à Jet qu'à Sybase puisque c'est ça qui était utilisé pour
stocker les données dans Exchange (leur erzatz de Lotus Notes).
--
Th. Thomas.
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage Transact-SQL (du style PL/SQL) était exactement le même. Ensuite, ça a dû diverger petit à petit : MS a commencé par virer la portabilité pour que ça ne tourne plus que sur Windows. Je ne sais plus où en est la compatibilité actuellement, mais le protocole d'accès est au moins toujours le même, puisque FreeTDS permet toujours d'accéder aux deux types de bases. Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Parallélement, MS bricolait son moteur Jet, qui n'a rien à voir avec Sybase, et qui le c½ur d'Access. Bizarrement, ils faisaient plus confiance à Jet qu'à Sybase puisque c'est ça qui était utilisé pour stocker les données dans Exchange (leur erzatz de Lotus Notes). -- Th. Thomas.
Stéphane CARPENTIER
helios wrote:
pick sait creer les utilisateur unix ou installer un peripherique unix ce que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus de droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root, il pourra te virer ta base de données (que ce soit pick ou Oracle), te détruire tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais ses droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi effacer tes disques durs (tu as écrit toi même qu'il sait installer un périphérique, comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton système. Au niveau sécurité, c'est très mauvais.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
helios wrote:
pick sait creer les utilisateur unix ou installer un peripherique unix ce
que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus de
droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De
Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root, il
pourra te virer ta base de données (que ce soit pick ou Oracle), te détruire
tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les
droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais ses
droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute
ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi effacer
tes disques durs (tu as écrit toi même qu'il sait installer un périphérique,
comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton
système. Au niveau sécurité, c'est très mauvais.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
pick sait creer les utilisateur unix ou installer un peripherique unix ce que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus de droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root, il pourra te virer ta base de données (que ce soit pick ou Oracle), te détruire tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais ses droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi effacer tes disques durs (tu as écrit toi même qu'il sait installer un périphérique, comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton système. Au niveau sécurité, c'est très mauvais.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Jerome Lambert
[J'avais coupé un peu vite...]
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les articles de fichier modifier imagine le modele en relationnelle et en mv tu comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2 lignes
Oui, mais tout est alors mélangé... Et bien soit la base de données MV suivante:
NOM CONNEXIONS Fichiers_ouverts Jerome 12:30;13:20;14:00 toto.txt;titi.txt,tutu.txt
Comment je peux savoir lors de quelle connexion quels fichiers ont été ouverts? Si c'est trois max. par connexion, alors ce serait:
NOM CONNEXIONS Fichiers_ouverts Jerome 12:30;13:20;14:00 0;0;0;toto.txt;0;0;titi.txt;tutu.txt;0
alors on voit que toto.txt a été ouvert à la deuxième connexion, mais on génère alors 6 champs vides... En SGBDR, cela donnerait avec les liens
Table 1 +->ID NOM I 01 Jerome I I Table 2 Table 3 +->ID CONNEXION N.<--->N. Fichiers_ouverts 01 12:30 1 2 toto.txt 01 13:20 2 3 titi.txt 01 14:00 3 3 tutu.txt
A part les numéros (bien obligé), pas de redondance inutile, seulement 7 lignes, et pas de champs inutilement vides...
[J'avais coupé un peu vite...]
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en
l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le
nom qui servirait de clef car un id numerique serait inutile contrairement
au relationnel car le nom est une clef unique
ce qui donne :
NOM CONNEXIONS
Jerome 12:30;13:20;14:00
Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les
articles de fichier modifier imagine le modele en relationnelle et en mv tu
comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le
relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2
lignes
Oui, mais tout est alors mélangé...
Et bien soit la base de données MV suivante:
NOM CONNEXIONS Fichiers_ouverts
Jerome 12:30;13:20;14:00 toto.txt;titi.txt,tutu.txt
Comment je peux savoir lors de quelle connexion quels fichiers ont été
ouverts?
Si c'est trois max. par connexion, alors ce serait:
NOM CONNEXIONS Fichiers_ouverts
Jerome 12:30;13:20;14:00 0;0;0;toto.txt;0;0;titi.txt;tutu.txt;0
alors on voit que toto.txt a été ouvert à la deuxième connexion, mais on
génère alors 6 champs vides...
En SGBDR, cela donnerait avec les liens
Table 1
+->ID NOM
I 01 Jerome
I
I Table 2 Table 3
+->ID CONNEXION N.<--->N. Fichiers_ouverts
01 12:30 1 2 toto.txt
01 13:20 2 3 titi.txt
01 14:00 3 3 tutu.txt
A part les numéros (bien obligé), pas de redondance inutile, seulement 7
lignes, et pas de champs inutilement vides...
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les articles de fichier modifier imagine le modele en relationnelle et en mv tu comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2 lignes
Oui, mais tout est alors mélangé... Et bien soit la base de données MV suivante:
NOM CONNEXIONS Fichiers_ouverts Jerome 12:30;13:20;14:00 toto.txt;titi.txt,tutu.txt
Comment je peux savoir lors de quelle connexion quels fichiers ont été ouverts? Si c'est trois max. par connexion, alors ce serait:
NOM CONNEXIONS Fichiers_ouverts Jerome 12:30;13:20;14:00 0;0;0;toto.txt;0;0;titi.txt;tutu.txt;0
alors on voit que toto.txt a été ouvert à la deuxième connexion, mais on génère alors 6 champs vides... En SGBDR, cela donnerait avec les liens
Table 1 +->ID NOM I 01 Jerome I I Table 2 Table 3 +->ID CONNEXION N.<--->N. Fichiers_ouverts 01 12:30 1 2 toto.txt 01 13:20 2 3 titi.txt 01 14:00 3 3 tutu.txt
A part les numéros (bien obligé), pas de redondance inutile, seulement 7 lignes, et pas de champs inutilement vides...
Stephane TOUGARD
helios wrote:
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME REMY
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30 13:20 14:00
Dis donc, c'est vraiment impressionnant ce qu'on peut faire avec Pick. Je pensais pas que ca allait si loin.
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
Ah ben oui, c'est logique. Ah dis donc, c'est super fort. Je presume qu'en plus sur une table a deux index, comme celle-la, les reponses sont presque instantanees, tu demandes les connexions de Jerome et en quelques secondes t'as le resultat.
-- 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
helios wrote:
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME
REMY
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30
13:20
14:00
Dis donc, c'est vraiment impressionnant ce qu'on peut faire avec Pick.
Je pensais pas que ca allait si loin.
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le
nom qui servirait de clef car un id numerique serait inutile contrairement
au relationnel car le nom est une clef unique
ce qui donne :
NOM CONNEXIONS
Jerome 12:30;13:20;14:00
Remy 12:45;13:45;14:00
Ah ben oui, c'est logique. Ah dis donc, c'est super fort. Je presume
qu'en plus sur une table a deux index, comme celle-la, les reponses sont
presque instantanees, tu demandes les connexions de Jerome et en
quelques secondes t'as le resultat.
--
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
Dis donc, c'est vraiment impressionnant ce qu'on peut faire avec Pick. Je pensais pas que ca allait si loin.
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
Ah ben oui, c'est logique. Ah dis donc, c'est super fort. Je presume qu'en plus sur une table a deux index, comme celle-la, les reponses sont presque instantanees, tu demandes les connexions de Jerome et en quelques secondes t'as le resultat.
-- 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
Vincent Bernat wrote:
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout les fichiers et droit du sgbd donc pick a plus de securite puisque que cracke le remote ne suffit pas
Stéphane, bon courage !
C'est un champion du monde.
-- 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
Vincent Bernat wrote:
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le
system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens
tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout
les fichiers et droit du sgbd donc pick a plus de securite puisque que
cracke le remote ne suffit pas
Stéphane, bon courage !
C'est un champion du monde.
--
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
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout les fichiers et droit du sgbd donc pick a plus de securite puisque que cracke le remote ne suffit pas
Stéphane, bon courage !
C'est un champion du monde.
-- 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
JustMe wrote:
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme pas mal de systèmes performants qui se respectent.
pas besoin d'acces root pour ca.
Qui plus helios conseillait de prendre un Linux Live pour l'essayer, le conseil meme me fait douter de ce type d'ecriture.
Anyway, vraiment pas besoin d'acces root pour ca, l'acces a un device est tres largement suffisant.
-- 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
JustMe wrote:
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem
Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file
systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme
pas mal de systèmes performants qui se respectent.
pas besoin d'acces root pour ca.
Qui plus helios conseillait de prendre un Linux Live pour l'essayer, le
conseil meme me fait douter de ce type d'ecriture.
Anyway, vraiment pas besoin d'acces root pour ca, l'acces a un device
est tres largement suffisant.
--
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
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme pas mal de systèmes performants qui se respectent.
pas besoin d'acces root pour ca.
Qui plus helios conseillait de prendre un Linux Live pour l'essayer, le conseil meme me fait douter de ce type d'ecriture.
Anyway, vraiment pas besoin d'acces root pour ca, l'acces a un device est tres largement suffisant.
-- 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
helios wrote:
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces au fichier de toto de titi et tout les autre donc une fois crack le remote toto on se retrouve avec l'acces au fichier de l'ensemble des users oracle tandis que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
Ces vieux systemes obsoletes embarquent souvent un modele de securite assez eleve au niveau de la gestion des Users.
En fait, ca parle quand meme avec un process en root, parce qu'il faut bien emuler le mecanisme au dessus de la couche Unix, mais c'est relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la table user systeme et la table user pick sont melanges.
Bref, c'est crade et vraiment pas safe.
-- 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
helios wrote:
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces au
fichier de toto de titi et tout les autre donc une fois crack le remote toto
on se retrouve avec l'acces au fichier de l'ensemble des users oracle tandis
que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a
ses fichiers comme Unix et l'acces multi-utilisateur est gere par un
systeme de securite type ACL.
Ces vieux systemes obsoletes embarquent souvent un modele de securite
assez eleve au niveau de la gestion des Users.
En fait, ca parle quand meme avec un process en root, parce qu'il faut
bien emuler le mecanisme au dessus de la couche Unix, mais c'est
relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la
table user systeme et la table user pick sont melanges.
Bref, c'est crade et vraiment pas safe.
--
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
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces au fichier de toto de titi et tout les autre donc une fois crack le remote toto on se retrouve avec l'acces au fichier de l'ensemble des users oracle tandis que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
Ces vieux systemes obsoletes embarquent souvent un modele de securite assez eleve au niveau de la gestion des Users.
En fait, ca parle quand meme avec un process en root, parce qu'il faut bien emuler le mecanisme au dessus de la couche Unix, mais c'est relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la table user systeme et la table user pick sont melanges.
Bref, c'est crade et vraiment pas safe.
-- 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
helios wrote:
justement c'est la la faille il suffit de planter le process commun pour avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le serveur comprend la requete et te retourne le resultat. Le temps perdu par les couches protocolaires est derisoire, par contre le gain en convivialite, en securite et en portabilite sont phenomenales.
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
-- 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
helios wrote:
justement c'est la la faille il suffit de planter le process commun pour
avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick
tourne en root.
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le
serveur comprend la requete et te retourne le resultat. Le temps perdu par les
couches protocolaires est derisoire, par contre le gain en convivialite,
en securite et en portabilite sont phenomenales.
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
--
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
justement c'est la la faille il suffit de planter le process commun pour avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le serveur comprend la requete et te retourne le resultat. Le temps perdu par les couches protocolaires est derisoire, par contre le gain en convivialite, en securite et en portabilite sont phenomenales.
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
-- 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
helios wrote:
tu archive de-tar par http avant ensuite th more fait pour que radme fichier tyu lire peux. sais quand maime pas si compliquer que ca dire le
ce readmi ficher caen meme meme que quand m'aime.
ensuite, tu suie les zinformation fu dichier RIDEMI est tu lanse le serveur en moin de 10 minuts. je te parles du fichier README pas de celui qui est dans une archive
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme moi je comprends pas. Je crois que ce type vient d'une autre planete et parle 32000 dialectes.
Ah non, j'ai compris, helios c'est le petit de grand frere de 6PO qui gere 6 000 000 sur une base pick.
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Pour arriver a comprendre un texte que meme l'auteur ne peut pas comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton cerveau.
Je comprend pas pourquoi des gens te plonkent, t'es un marrant a un point qu'on imagine pas. Moi c'est simple, je pensais que dans le "Diner de cons" ils avaient pris un cas extreme, et ben non, sur fcold on a un exemple de dans la vraie vie. Un champion du monde.
-- 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
helios wrote:
tu archive de-tar par http avant ensuite th more fait pour que radme
fichier tyu lire peux. sais quand maime pas si compliquer que ca dire
le
ce readmi ficher caen meme meme que quand m'aime.
ensuite, tu suie les zinformation fu dichier RIDEMI est tu lanse le
serveur en moin de 10 minuts.
je te parles du fichier README pas de celui qui est dans une archive
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme
moi je comprends pas. Je crois que ce type vient d'une autre planete et
parle 32000 dialectes.
Ah non, j'ai compris, helios c'est le petit de grand frere de 6PO qui
gere 6 000 000 sur une base pick.
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une
communication avec un taux d'antropie important .
Pour arriver a comprendre un texte que meme l'auteur ne peut pas
comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis
l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton
cerveau.
Je comprend pas pourquoi des gens te plonkent, t'es un marrant a un point
qu'on imagine pas. Moi c'est simple, je pensais que dans le "Diner de
cons" ils avaient pris un cas extreme, et ben non, sur fcold on a un
exemple de dans la vraie vie. Un champion du monde.
--
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
tu archive de-tar par http avant ensuite th more fait pour que radme fichier tyu lire peux. sais quand maime pas si compliquer que ca dire le
ce readmi ficher caen meme meme que quand m'aime.
ensuite, tu suie les zinformation fu dichier RIDEMI est tu lanse le serveur en moin de 10 minuts. je te parles du fichier README pas de celui qui est dans une archive
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme moi je comprends pas. Je crois que ce type vient d'une autre planete et parle 32000 dialectes.
Ah non, j'ai compris, helios c'est le petit de grand frere de 6PO qui gere 6 000 000 sur une base pick.
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Pour arriver a comprendre un texte que meme l'auteur ne peut pas comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton cerveau.
Je comprend pas pourquoi des gens te plonkent, t'es un marrant a un point qu'on imagine pas. Moi c'est simple, je pensais que dans le "Diner de cons" ils avaient pris un cas extreme, et ben non, sur fcold on a un exemple de dans la vraie vie. Un champion du monde.
-- 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
