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
JE ME REPETES QUAND ON A UNE LAMBORGUINI ON SE MOQUE DU FONCTIONNEMENT DE LA 2CV
Ne crie pas s'il te plaît. En plus ton exemple est mauvais : une lamborghini et une 2CV ont le même fonctionnement "de base". De ce que
et en plus la lambo n'est meme pas foutu de remplir le cahier des charges initial de la 2CV (1937)
Alors, supérieure, pfff... ca depend de ce qu'on veut en faire :-D
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
je comprend ta haine d'un systeme qui va te metre au chomage si tu te reconvertie pas
Mouarf, avant que ton truc vienne remplacer la palanquee de serveurs Oracle, PostgreSQL ou MySQL, que ca inverse la tendance sur les programmes en PHP, en Perl ou en Python a peu pres partout ... il risque de couler beaucoup d'eau sous les ponts.
qui aurais cru en 1985 que dbase disparaitrait, dbase etait partout : dbase,
clipper, paradox ....... quiest encore sous clipper ?
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:83ier2-nmi.ln1@gulliver.unices.org...
helios wrote:
je comprend ta haine d'un systeme qui va te metre au chomage si tu te
reconvertie pas
Mouarf, avant que ton truc vienne remplacer la palanquee de serveurs
Oracle, PostgreSQL ou MySQL, que ca inverse la tendance sur les
programmes en PHP, en Perl ou en Python a peu pres partout ... il risque
de couler beaucoup d'eau sous les ponts.
qui aurais cru en 1985 que dbase disparaitrait, dbase etait partout : dbase,
clipper, paradox ....... quiest encore sous clipper ?
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
je comprend ta haine d'un systeme qui va te metre au chomage si tu te reconvertie pas
Mouarf, avant que ton truc vienne remplacer la palanquee de serveurs Oracle, PostgreSQL ou MySQL, que ca inverse la tendance sur les programmes en PHP, en Perl ou en Python a peu pres partout ... il risque de couler beaucoup d'eau sous les ponts.
qui aurais cru en 1985 que dbase disparaitrait, dbase etait partout : dbase,
clipper, paradox ....... quiest encore sous clipper ?
helios
C'est quoi le multivaleur précisément ? S'agit-il simplement de pouvoir utiliser un type "tableau" ?
http://www.bvr.be/openqm/id30.htm
C'est quoi le multivaleur précisément ? S'agit-il simplement de pouvoir
utiliser un type "tableau" ?
C'est quoi le multivaleur précisément ? S'agit-il simplement de pouvoir utiliser un type "tableau" ?
http://www.bvr.be/openqm/id30.htm
Stephane TOUGARD
helios wrote:
JE ME REPETES QUAND ON A UNE LAMBORGUINI ON SE MOQUE DU FONCTIONNEMENT DE LA 2CV
Dans ton cas, il faudrait deja apprendre a conduire.
si il apparait comme une connection oracle cela signifie que c'est une passoire car ton utilisateur n'est pas gerer donc anonyme pour le system et en cas de sortie d'oracle il se retrouve avec les privileges oracle bonjour la securite
C'est toujours mieux que root.
avec un system pick , l'utilisateur sous pick est connu et gerer au niveau du system et en cas de sortie de la base de donne il est soit deconnecte soit bloque avec des privileges reduit a ses acces au system pick donc ne peut rien faire de plus que sous le system pick avec son login
Mais non, sous Oracle (comme sous toute base de donnee), l'utilisateur est connecte via un protocole reseau, il n'est jamais connecte sur la machine en elle meme. On ne le voie pas au niveau systeme, parce qu'il n'arrive jamais sur le systeme. Il ne peut meme pas rever d'un login, il n'a pas de login.
D'ailleurs, la plupart du temps il est meme pas connecte en reseau, il parle avec une application qui elle est connecte via un protocole reseau et tres souvent sur des serveurs separes.
Sous Pick, l'utilisateur est deja connecte en direct sur le serveur (ce qui est deja pire) et en plus via un protocole local a un process serveur qui lui meme court en root (ce qui est limite desastreux).
Je te suggere de t'interesser a comment fonctionne la 2CV, ca te permettra de voir un systeme ou la securite est pensee et peut etre (si tu en as les competences) d'ameliorer ton truc.
-- 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:
JE ME REPETES QUAND ON A UNE LAMBORGUINI ON SE MOQUE DU FONCTIONNEMENT DE LA
2CV
Dans ton cas, il faudrait deja apprendre a conduire.
si il apparait comme une connection oracle cela signifie que c'est une
passoire car ton utilisateur n'est pas gerer donc anonyme pour le system et
en cas de sortie d'oracle il se retrouve avec les privileges oracle bonjour
la securite
C'est toujours mieux que root.
avec un system pick , l'utilisateur sous pick est connu et gerer au niveau
du system et en cas de sortie de la base de donne il est soit deconnecte
soit bloque avec des privileges reduit a ses acces au system pick donc ne
peut rien faire de plus que sous le system pick avec son login
Mais non, sous Oracle (comme sous toute base de donnee), l'utilisateur
est connecte via un protocole reseau, il n'est jamais connecte sur la
machine en elle meme. On ne le voie pas au niveau systeme, parce qu'il
n'arrive jamais sur le systeme. Il ne peut meme pas rever d'un login, il
n'a pas de login.
D'ailleurs, la plupart du temps il est meme pas connecte en reseau, il
parle avec une application qui elle est connecte via un protocole
reseau et tres souvent sur des serveurs separes.
Sous Pick, l'utilisateur est deja connecte en direct sur le serveur (ce
qui est deja pire) et en plus via un protocole local a un process
serveur qui lui meme court en root (ce qui est limite desastreux).
Je te suggere de t'interesser a comment fonctionne la 2CV, ca te
permettra de voir un systeme ou la securite est pensee et peut etre
(si tu en as les competences) d'ameliorer ton truc.
--
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
JE ME REPETES QUAND ON A UNE LAMBORGUINI ON SE MOQUE DU FONCTIONNEMENT DE LA 2CV
Dans ton cas, il faudrait deja apprendre a conduire.
si il apparait comme une connection oracle cela signifie que c'est une passoire car ton utilisateur n'est pas gerer donc anonyme pour le system et en cas de sortie d'oracle il se retrouve avec les privileges oracle bonjour la securite
C'est toujours mieux que root.
avec un system pick , l'utilisateur sous pick est connu et gerer au niveau du system et en cas de sortie de la base de donne il est soit deconnecte soit bloque avec des privileges reduit a ses acces au system pick donc ne peut rien faire de plus que sous le system pick avec son login
Mais non, sous Oracle (comme sous toute base de donnee), l'utilisateur est connecte via un protocole reseau, il n'est jamais connecte sur la machine en elle meme. On ne le voie pas au niveau systeme, parce qu'il n'arrive jamais sur le systeme. Il ne peut meme pas rever d'un login, il n'a pas de login.
D'ailleurs, la plupart du temps il est meme pas connecte en reseau, il parle avec une application qui elle est connecte via un protocole reseau et tres souvent sur des serveurs separes.
Sous Pick, l'utilisateur est deja connecte en direct sur le serveur (ce qui est deja pire) et en plus via un protocole local a un process serveur qui lui meme court en root (ce qui est limite desastreux).
Je te suggere de t'interesser a comment fonctionne la 2CV, ca te permettra de voir un systeme ou la securite est pensee et peut etre (si tu en as les competences) d'ameliorer ton truc.
-- 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:
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant a ta connection pour obtenir un shell root il faudrait que tu te soit connecter root au depart
Qu'est ce que tu en sais ?
Je veux dire que l'acces au fichiers de bases sont regules par des droits et que n'importe quel utilisateur ne peut pas les lire ou y ecrire.
Donc, il faut bien que l'utilisateur toto soit connecte par un quelconque protocole a un process qui a des droits sur ces fichiers.
Sous ton systeme, cette base tourne sous root, ce qui veut dire que si ce fameux process est craque, alors, ton utilisateur prend les droits root.
Qui plus est, comme ton utilisateur a un acces local sur la machine, il peut au moins prendre un shell sur la dite machine, meme si non privilegie, il beneficie alors de tous les exploits locaux (ce qui ne manque pas).
Avec un SGBD conventionnel, l'utilisateur est en relation avec le dit process via une connexion reseau et souvent via une autre application.
Quand au fameux process qui parle avec les fichiers, lui meme n'est pas root, donc meme si il est acque, l'utilisateur a une marge de maneoeuvre de moins (d'ailleur souvent, cet utilisateur n'a pas de shell lui meme, ce qui ameliore encore la securite).
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au moins.
-- 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:
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant
a ta connection pour obtenir un shell root il faudrait que tu te soit
connecter root au depart
Qu'est ce que tu en sais ?
Je veux dire que l'acces au fichiers de bases sont regules par des
droits et que n'importe quel utilisateur ne peut pas les lire ou y
ecrire.
Donc, il faut bien que l'utilisateur toto soit connecte par un
quelconque protocole a un process qui a des droits sur ces fichiers.
Sous ton systeme, cette base tourne sous root, ce qui veut dire que si
ce fameux process est craque, alors, ton utilisateur prend les droits
root.
Qui plus est, comme ton utilisateur a un acces local sur la machine, il
peut au moins prendre un shell sur la dite machine, meme si non
privilegie, il beneficie alors de tous les exploits locaux (ce qui ne
manque pas).
Avec un SGBD conventionnel, l'utilisateur est en relation avec le dit
process via une connexion reseau et souvent via une autre application.
Quand au fameux process qui parle avec les fichiers, lui meme n'est pas
root, donc meme si il est acque, l'utilisateur a une marge de maneoeuvre
de moins (d'ailleur souvent, cet utilisateur n'a pas de shell lui meme,
ce qui ameliore encore la securite).
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au
moins.
--
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
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant a ta connection pour obtenir un shell root il faudrait que tu te soit connecter root au depart
Qu'est ce que tu en sais ?
Je veux dire que l'acces au fichiers de bases sont regules par des droits et que n'importe quel utilisateur ne peut pas les lire ou y ecrire.
Donc, il faut bien que l'utilisateur toto soit connecte par un quelconque protocole a un process qui a des droits sur ces fichiers.
Sous ton systeme, cette base tourne sous root, ce qui veut dire que si ce fameux process est craque, alors, ton utilisateur prend les droits root.
Qui plus est, comme ton utilisateur a un acces local sur la machine, il peut au moins prendre un shell sur la dite machine, meme si non privilegie, il beneficie alors de tous les exploits locaux (ce qui ne manque pas).
Avec un SGBD conventionnel, l'utilisateur est en relation avec le dit process via une connexion reseau et souvent via une autre application.
Quand au fameux process qui parle avec les fichiers, lui meme n'est pas root, donc meme si il est acque, l'utilisateur a une marge de maneoeuvre de moins (d'ailleur souvent, cet utilisateur n'a pas de shell lui meme, ce qui ameliore encore la securite).
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au moins.
-- 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
bon alors je vais t'expliquer
une base cela sert a stocker les donnees pour traitement ou consultation et cela se sont les applicatifs en gros il y a une/des surcouches l'epoque du mec derriere son tty en mode texte devient rare de nos jours
et tous ses applicatifs ils ont besoin de quoi d'un standard pour extraire les donnees """la requete pick""" a la syntaxe maison cela ne fait pas l'affaire ou alors il faut a chaque fois reformer le personnel ou reecrire tous les applicatifs
c'est plus clair
il ne te reste plus qu'a creer ou pomper un dico sql que tu mets sur une base pick et la franchement tu gagnes quoi ?
une eventuelle compatibilite avec une vieille base au sql non standard cela peut etre pratique pourquoi pas mais il vaut mieux faire les choses de maniere propre ,plutot que de se trainer une vieille incompatilibite
ca c'est pour ce que j'en ai compris d'un point de vue technique les raisons qu'un client peut avoir pour changer de fournisseur je te les laisse imaginer
le dico pick sait gerer le sql mais pourquoi se limiter au sql ? en gros le system Pick est le theoreme de ferrarri (resolution equation du 4eme degres) et sql est la methode du discriminant (la methode du discriminant permet de resoudre certaine equation du 3em et 4eme degres et celle du 2eme le theo de ferrari permet de resoudre toute les equation du 2em 3em et 4em degres)
un frontal sql peut interroger une base pick si celle ci s'est limiter au singlevalue
bon alors je vais t'expliquer
une base cela sert a stocker les donnees pour traitement ou consultation
et cela se sont les applicatifs en gros il y a une/des surcouches
l'epoque du mec derriere son tty en mode texte devient rare
de nos jours
et tous ses applicatifs ils ont besoin de quoi d'un standard pour extraire
les donnees """la requete pick""" a la syntaxe maison cela ne
fait pas l'affaire ou alors il faut a chaque fois reformer le personnel
ou reecrire tous les applicatifs
c'est plus clair
il ne te reste plus qu'a creer ou pomper un dico sql que tu mets sur une
base pick et la franchement tu gagnes quoi ?
une eventuelle compatibilite avec une vieille base au sql non standard
cela peut etre pratique pourquoi pas mais il vaut mieux
faire les choses de maniere propre ,plutot que de se trainer une vieille
incompatilibite
ca c'est pour ce que j'en ai compris d'un point de vue technique
les raisons qu'un client peut avoir pour changer de fournisseur
je te les laisse imaginer
le dico pick sait gerer le sql mais pourquoi se limiter au sql ? en gros le
system Pick est le theoreme de ferrarri (resolution equation du 4eme degres)
et sql est la methode du discriminant (la methode du discriminant permet de
resoudre certaine equation du 3em et 4eme degres et celle du 2eme le theo
de ferrari permet de resoudre toute les equation du 2em 3em et 4em degres)
un frontal sql peut interroger une base pick si celle ci s'est limiter au
singlevalue
une base cela sert a stocker les donnees pour traitement ou consultation et cela se sont les applicatifs en gros il y a une/des surcouches l'epoque du mec derriere son tty en mode texte devient rare de nos jours
et tous ses applicatifs ils ont besoin de quoi d'un standard pour extraire les donnees """la requete pick""" a la syntaxe maison cela ne fait pas l'affaire ou alors il faut a chaque fois reformer le personnel ou reecrire tous les applicatifs
c'est plus clair
il ne te reste plus qu'a creer ou pomper un dico sql que tu mets sur une base pick et la franchement tu gagnes quoi ?
une eventuelle compatibilite avec une vieille base au sql non standard cela peut etre pratique pourquoi pas mais il vaut mieux faire les choses de maniere propre ,plutot que de se trainer une vieille incompatilibite
ca c'est pour ce que j'en ai compris d'un point de vue technique les raisons qu'un client peut avoir pour changer de fournisseur je te les laisse imaginer
le dico pick sait gerer le sql mais pourquoi se limiter au sql ? en gros le system Pick est le theoreme de ferrarri (resolution equation du 4eme degres) et sql est la methode du discriminant (la methode du discriminant permet de resoudre certaine equation du 3em et 4eme degres et celle du 2eme le theo de ferrari permet de resoudre toute les equation du 2em 3em et 4em degres)
un frontal sql peut interroger une base pick si celle ci s'est limiter au singlevalue
Emmanuel Florac
Le Mon, 25 Jul 2005 13:55:32 +0200, helios a écrit :
les proprietaire de lamborguinio n'on jamais eu besoin de connaitre le fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la lamborguini
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à chier et la 2CV nickel. Idem si tu accorde de l'importance à la quantité de carburant et au coût d'entretien de la bagnole. Une deudeuche ne craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut traverser le sahara ou un champ labouré. C'est beaucoup plus solide et polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
-- entia non sont multiplicanda praeter necessitatem. John Ponce of Cork.
Le Mon, 25 Jul 2005 13:55:32 +0200, helios a écrit :
les proprietaire de lamborguinio n'on jamais eu besoin de connaitre le
fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la
lamborguini
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un
champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à
chier et la 2CV nickel. Idem si tu accorde de l'importance à la quantité
de carburant et au coût d'entretien de la bagnole. Une deudeuche ne
craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut
traverser le sahara ou un champ labouré. C'est beaucoup plus solide et
polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.
Le Mon, 25 Jul 2005 13:55:32 +0200, helios a écrit :
les proprietaire de lamborguinio n'on jamais eu besoin de connaitre le fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la lamborguini
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à chier et la 2CV nickel. Idem si tu accorde de l'importance à la quantité de carburant et au coût d'entretien de la bagnole. Une deudeuche ne craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut traverser le sahara ou un champ labouré. C'est beaucoup plus solide et polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
-- entia non sont multiplicanda praeter necessitatem. John Ponce of Cork.
helios
"JustMe" a écrit dans le message de news:
Jerome Lambert a pensé très fort :
Et toi tu ne sais décidément pas lire, ou tout du moins tu ne comprends pas
ce que tu lis. Stéphane demande pourquoi Pick veut assurer des fonctions normalement assignées à un OS, je lui réponds en lui citant le passage expliquant qu'initialement, Pick faisait à la fois SGBD et OS, et donc que le
fait que, encore de nos jours, Pick veuille en partie se substituer à l'OS
est une réminiscence due à sa conception initiale.
comme le cerveau reptilien hérité de nos ancètres dinosaures ? ;-)
enleve le cerveau reptilien et tu obtient un legume
"JustMe" <pasdespam@merci.beaucoup> a écrit dans le message de
news:mn.ca6a7d57eac24e0a.15643@merci.beaucoup...
Jerome Lambert a pensé très fort :
Et toi tu ne sais décidément pas lire, ou tout du moins tu ne comprends
pas
ce que tu lis. Stéphane demande pourquoi Pick veut assurer des fonctions
normalement assignées à un OS, je lui réponds en lui citant le passage
expliquant qu'initialement, Pick faisait à la fois SGBD et OS, et donc
que le
fait que, encore de nos jours, Pick veuille en partie se substituer à
l'OS
est une réminiscence due à sa conception initiale.
comme le cerveau reptilien hérité de nos ancètres dinosaures ? ;-)
enleve le cerveau reptilien et tu obtient un legume
Et toi tu ne sais décidément pas lire, ou tout du moins tu ne comprends pas
ce que tu lis. Stéphane demande pourquoi Pick veut assurer des fonctions normalement assignées à un OS, je lui réponds en lui citant le passage expliquant qu'initialement, Pick faisait à la fois SGBD et OS, et donc que le
fait que, encore de nos jours, Pick veuille en partie se substituer à l'OS
est une réminiscence due à sa conception initiale.
comme le cerveau reptilien hérité de nos ancètres dinosaures ? ;-)
enleve le cerveau reptilien et tu obtient un legume
Stephane Zuckerman
différents. Bref, ils ne sont pas comparables. C'est comme Windows Vs Linux. C'est bien beau de dire "quand on a un machin supérieur, pas la peine de voir comment fonctionne un machin inférieur". Ben en fait si. Sinon tu peux pas savoir si ledit machin est réellement inférieur.
la 2cv et la lamborguini sont deux vehicule a essence ils ont 4 roues et la comparaisons s'arrete presque la Ben non. Le principe du moteur est le même aussi. L'un est certes
"meilleur" (et encore, faut voir la consommation en essence de chaque), mais les deux se basent quand même sur le moteur à explosion, non ? C'est bien plus proche au niveau de fonctionnement (à mon sens, mais il est clair que je ne suis pas expert en automobiles ;-) ) que ta comparaison être humain/autres animaux.
les proprietaire de lamborguinio n'on jamais eu besoin de connaitre le
fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la lamborguini
Oui, mais à partir du moment où tu désires comparer deux choses, dans une approche scientifique, il faut que tu puisses donner les défauts de l'un et l'autre système. Et jusqu'à présent, tu as surtout montré que tu ne savais pas réellement comment était géré un SGBD utilisant SQL pour faire des requêtes.
Sous UNIX/Linux, si ton "système PICK" est lancé depuis le compte root, ça signifie que si je trouve une faille de sécurité dedans, et que j'obtiens un shell, j'ai les droits root. Point.
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant
a ta connection pour obtenir un shell root il faudrait que tu te soit connecter root au depart Explique-moi quelque chose. Admettons le fait qu'un système PICK détourne
certaines ressources système. Outre le fait que du coup tu risques d'altérer le comportement dudit système pour d'autres applications pouvant éventuellement tourner dessus, tu affirmes qu'un trou de sécurité dans "ton" SGBD, si ce dernier était lancé en tant que root, ne poserait pas de problème, car "l'utilisateur serait connecté avec ses droits et rien que ses droits". Je doute un peu (beaucoup en fait), parce que si je trouve le moyen de faire planter PICK, il plante avec les droits de root derrière lui. Donc si j'ai un shell code qui suit, je ne vois pas en quoi le fait d'avoir été "loggé" en tant que toto change le fait que PICK a été lancé sous root.
le seul moyen en etant connecter toto sous pick et en etant en shell d'avoir les droit root c'est de faire un su dans le shell et a ce moment le c'est linux qui dit halte dans un shell oracle tua s acces a tout les fichier oracle Euh non. Un "shell" oracle ne te laisse accès qu'à ce que ton DBA t'as
donné droit d'accéder. Idem pour PostgresSQL, MySQL, etc.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
différents. Bref, ils ne sont pas comparables. C'est comme Windows Vs
Linux. C'est bien beau de dire "quand on a un machin supérieur, pas la
peine de voir comment fonctionne un machin inférieur". Ben en fait si.
Sinon tu peux pas savoir si ledit machin est réellement inférieur.
la 2cv et la lamborguini sont deux vehicule a essence ils ont 4 roues et la
comparaisons s'arrete presque la
Ben non. Le principe du moteur est le même aussi. L'un est certes
"meilleur" (et encore, faut voir la consommation en essence de chaque),
mais les deux se basent quand même sur le moteur à explosion, non ? C'est
bien plus proche au niveau de fonctionnement (à mon sens, mais il est
clair que je ne suis pas expert en automobiles ;-) ) que ta comparaison
être humain/autres animaux.
les proprietaire de lamborguinio n'on jamais eu besoin de
connaitre le
fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la
lamborguini
Oui, mais à partir du moment où tu désires comparer deux choses, dans une
approche scientifique, il faut que tu puisses donner les défauts de l'un
et l'autre système. Et jusqu'à présent, tu as surtout montré que tu ne
savais pas réellement comment était géré un SGBD utilisant SQL pour faire
des requêtes.
Sous UNIX/Linux, si ton "système PICK" est lancé depuis le compte root, ça
signifie que si je trouve une faille de sécurité dedans, et que j'obtiens
un shell, j'ai les droits root. Point.
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant
a ta connection pour obtenir un shell root il faudrait que tu te soit
connecter root au depart
Explique-moi quelque chose. Admettons le fait qu'un système PICK détourne
certaines ressources système. Outre le fait que du coup tu risques
d'altérer le comportement dudit système pour d'autres applications pouvant
éventuellement tourner dessus, tu affirmes qu'un trou de sécurité dans
"ton" SGBD, si ce dernier était lancé en tant que root, ne poserait pas de
problème, car "l'utilisateur serait connecté avec ses droits et rien que
ses droits". Je doute un peu (beaucoup en fait), parce que si je trouve le
moyen de faire planter PICK, il plante avec les droits de root derrière
lui. Donc si j'ai un shell code qui suit, je ne vois pas en quoi le fait
d'avoir été "loggé" en tant que toto change le fait que PICK a été lancé
sous root.
le seul moyen en etant connecter toto sous pick et en etant en shell d'avoir
les droit root c'est de faire un su dans le shell et a ce moment le c'est
linux qui dit halte
dans un shell oracle tua s acces a tout les fichier oracle
Euh non. Un "shell" oracle ne te laisse accès qu'à ce que ton DBA t'as
donné droit d'accéder. Idem pour PostgresSQL, MySQL, etc.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
différents. Bref, ils ne sont pas comparables. C'est comme Windows Vs Linux. C'est bien beau de dire "quand on a un machin supérieur, pas la peine de voir comment fonctionne un machin inférieur". Ben en fait si. Sinon tu peux pas savoir si ledit machin est réellement inférieur.
la 2cv et la lamborguini sont deux vehicule a essence ils ont 4 roues et la comparaisons s'arrete presque la Ben non. Le principe du moteur est le même aussi. L'un est certes
"meilleur" (et encore, faut voir la consommation en essence de chaque), mais les deux se basent quand même sur le moteur à explosion, non ? C'est bien plus proche au niveau de fonctionnement (à mon sens, mais il est clair que je ne suis pas expert en automobiles ;-) ) que ta comparaison être humain/autres animaux.
les proprietaire de lamborguinio n'on jamais eu besoin de connaitre le
fonctionnement interne d'une 2cv pour savoir qu'elle est inferieure a la lamborguini
Oui, mais à partir du moment où tu désires comparer deux choses, dans une approche scientifique, il faut que tu puisses donner les défauts de l'un et l'autre système. Et jusqu'à présent, tu as surtout montré que tu ne savais pas réellement comment était géré un SGBD utilisant SQL pour faire des requêtes.
Sous UNIX/Linux, si ton "système PICK" est lancé depuis le compte root, ça signifie que si je trouve une faille de sécurité dedans, et que j'obtiens un shell, j'ai les droits root. Point.
non si tu obtient un shell c'est celui de l'utilisateur linux correspondant
a ta connection pour obtenir un shell root il faudrait que tu te soit connecter root au depart Explique-moi quelque chose. Admettons le fait qu'un système PICK détourne
certaines ressources système. Outre le fait que du coup tu risques d'altérer le comportement dudit système pour d'autres applications pouvant éventuellement tourner dessus, tu affirmes qu'un trou de sécurité dans "ton" SGBD, si ce dernier était lancé en tant que root, ne poserait pas de problème, car "l'utilisateur serait connecté avec ses droits et rien que ses droits". Je doute un peu (beaucoup en fait), parce que si je trouve le moyen de faire planter PICK, il plante avec les droits de root derrière lui. Donc si j'ai un shell code qui suit, je ne vois pas en quoi le fait d'avoir été "loggé" en tant que toto change le fait que PICK a été lancé sous root.
le seul moyen en etant connecter toto sous pick et en etant en shell d'avoir les droit root c'est de faire un su dans le shell et a ce moment le c'est linux qui dit halte dans un shell oracle tua s acces a tout les fichier oracle Euh non. Un "shell" oracle ne te laisse accès qu'à ce que ton DBA t'as
donné droit d'accéder. Idem pour PostgresSQL, MySQL, etc.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Stephane TOUGARD
helios wrote:
sous suystem pick un users fait le trajet suivant
Je modifie pour la forme
demarage linux demarage system pick login linux - connection system pick - travail - arret du system pick ou passage en shell utilisateur linux avec droit reduit a users system pick aucun acces autre que ceux prevu dans le system pick
crack du serveur qui tourne pick qui tourne sous root en utilisant un exploit local de securite.
deconnection arret linux
tandis que sous vos base le trajet est sauf erreur
demarage linux demarage le SGBD login sgbd connection sgbd travail arret du sgbd ou passage en shell
Pas de passage en Shell, c'est la la difference, tu es connecte sur un socket TCP selon un protocole propre a la base et ta seule chance d'esperer craquer le systeme se fait via un exploit remote.
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de cracker une machine via le reseau (et souvent via des programmes, voire des serveurs intermediaires) qu'en disposant d'un acces en local, quel qu'il soit.
-- 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:
sous suystem pick un users fait le trajet suivant
Je modifie pour la forme
demarage linux
demarage system pick
login linux - connection system pick - travail -
arret du system pick ou passage en shell
utilisateur linux avec droit reduit a users system pick
aucun acces autre que ceux prevu dans le system pick
crack du serveur qui tourne pick qui tourne sous root en utilisant un
exploit local de securite.
deconnection
arret linux
tandis que sous vos base le trajet est sauf erreur
demarage linux
demarage le SGBD
login sgbd
connection sgbd
travail
arret du sgbd ou passage en shell
Pas de passage en Shell, c'est la la difference, tu es connecte sur un
socket TCP selon un protocole propre a la base et ta seule chance
d'esperer craquer le systeme se fait via un exploit remote.
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit
remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de
cracker une machine via le reseau (et souvent via des programmes, voire
des serveurs intermediaires) qu'en disposant d'un acces en local, quel
qu'il soit.
--
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
demarage linux demarage system pick login linux - connection system pick - travail - arret du system pick ou passage en shell utilisateur linux avec droit reduit a users system pick aucun acces autre que ceux prevu dans le system pick
crack du serveur qui tourne pick qui tourne sous root en utilisant un exploit local de securite.
deconnection arret linux
tandis que sous vos base le trajet est sauf erreur
demarage linux demarage le SGBD login sgbd connection sgbd travail arret du sgbd ou passage en shell
Pas de passage en Shell, c'est la la difference, tu es connecte sur un socket TCP selon un protocole propre a la base et ta seule chance d'esperer craquer le systeme se fait via un exploit remote.
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de cracker une machine via le reseau (et souvent via des programmes, voire des serveurs intermediaires) qu'en disposant d'un acces en local, quel qu'il soit.
-- 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
