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
un system pick est au niveau du noyau du system c'est pour cela qu'il a besoin d'etre root et c'est ce qui le rend performant car il passes pas par les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur le disque pick ne passe pas par les interfaces c'est lui qui geres les interfaces quand il est lance
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 va lire tout seul comme un /etc/fstab pour retrouver ses petits et savoir sur quel peripherique physique il doit aller ecrire.
Comme il est portable, on peut considerer qu'il gere aussi l'UFS, le VFS, le HFS et le HFS+, sans parler de tous les FS que je ne connais pas et qui tournent sur Windows et tous les minis possibles et imaginables.
Qui plus est, comme il se place directement au niveau du noyau, il gere directement le materiel et comprend les instructions assembleurs pour tous les processeurs possibles et imaginables, en RISC comme en CISC, en 16 bit, 32 bit et 64 bit, en big Indian et en Little Indian, d'ailleurs suis je bete, il gere directement la plupart des controleurs IDE et SCSI ainsi que toutes les cartes reseau.
Mais pourquoi il boote pas tout seul ton truc ?
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire sur le steamer il utilise directement les drivers meme chose pour une imprimante il utilise directement le drivers sans passer par linux (linux est juste informe mais non utilise ) lorsque pick creer un users il le creer lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de controles.
C'est un OS, en quelque sorte.
-- 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:
un system pick est au niveau du noyau du system c'est pour cela qu'il a
besoin d'etre root et c'est ce qui le rend performant car il passes pas par
les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui
sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur
le disque pick ne passe pas par les interfaces c'est lui qui geres les
interfaces quand il est lance
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 va lire tout seul comme un /etc/fstab pour retrouver ses petits et
savoir sur quel peripherique physique il doit aller ecrire.
Comme il est portable, on peut considerer qu'il gere aussi l'UFS, le
VFS, le HFS et le HFS+, sans parler de tous les FS que je ne connais pas
et qui tournent sur Windows et tous les minis possibles et imaginables.
Qui plus est, comme il se place directement au niveau du noyau, il gere
directement le materiel et comprend les instructions assembleurs pour
tous les processeurs possibles et imaginables, en RISC comme en CISC, en
16 bit, 32 bit et 64 bit, en big Indian et en Little Indian, d'ailleurs
suis je bete, il gere directement la plupart des controleurs IDE et SCSI
ainsi que toutes les cartes reseau.
Mais pourquoi il boote pas tout seul ton truc ?
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire
sur le steamer il utilise directement les drivers meme chose pour une
imprimante il utilise directement le drivers sans passer par linux (linux
est juste informe mais non utilise ) lorsque pick creer un users il le creer
lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de
controles.
C'est un OS, en quelque sorte.
--
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
un system pick est au niveau du noyau du system c'est pour cela qu'il a besoin d'etre root et c'est ce qui le rend performant car il passes pas par les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur le disque pick ne passe pas par les interfaces c'est lui qui geres les interfaces quand il est lance
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 va lire tout seul comme un /etc/fstab pour retrouver ses petits et savoir sur quel peripherique physique il doit aller ecrire.
Comme il est portable, on peut considerer qu'il gere aussi l'UFS, le VFS, le HFS et le HFS+, sans parler de tous les FS que je ne connais pas et qui tournent sur Windows et tous les minis possibles et imaginables.
Qui plus est, comme il se place directement au niveau du noyau, il gere directement le materiel et comprend les instructions assembleurs pour tous les processeurs possibles et imaginables, en RISC comme en CISC, en 16 bit, 32 bit et 64 bit, en big Indian et en Little Indian, d'ailleurs suis je bete, il gere directement la plupart des controleurs IDE et SCSI ainsi que toutes les cartes reseau.
Mais pourquoi il boote pas tout seul ton truc ?
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire sur le steamer il utilise directement les drivers meme chose pour une imprimante il utilise directement le drivers sans passer par linux (linux est juste informe mais non utilise ) lorsque pick creer un users il le creer lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de controles.
C'est un OS, en quelque sorte.
-- 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
talon
helios wrote:
si tu plante pick en etant connecter toto tu te retrouve connecter toto
(dans le meilleur des cas) pas root ou completement deconnecte de linux
Tu reviendras nous voir quand tu connaîtras quelque chose à ce dont tu parles. Pour le moment va à la plage.
helios <helios@com02.com> wrote:
si tu plante pick en etant connecter toto tu te retrouve connecter toto
(dans le meilleur des cas) pas root ou completement deconnecte de linux
Tu reviendras nous voir quand tu connaîtras quelque chose à ce dont tu
parles. Pour le moment va à la plage.
OoO En ce début d'après-midi ensoleillé du lundi 25 juillet 2005, vers 15:06, "helios" disait:
si tu trouves une faille de securite linux tu es root aussi et trouver une faille securite pick revient a trouver une faille linux
La sécurité, c'est simple. -- I gave up on finding an answer and started drinking. -+- KM in: Guide du Cabaliste Usenet - Définir le consensus ? -+-
Stephane Zuckerman
le fait qu'un profane en sql a trouve une solution par "automate" que les gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
-- "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)
le fait qu'un profane en sql a trouve une solution par "automate" que les
gourrous n'ont pas trouve me fait douter du niveau des dit gourrous
la solution "automate" fonctionne je penses qu'elle doit etre lourde en
ressources machine par rapport a un sgbdMV mais bon le critere performance
n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle
la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et
je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution
de départ pour développer des requêtes sur UN SGBD. Concernant la
lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD
utilisant SQL, tu ne peux pas réellement émettre un avis sur la
performance (ou son absence) de telles requêtes. D'autant plus que cela
dépendra fortement du SGBD choisi.
--
"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)
le fait qu'un profane en sql a trouve une solution par "automate" que les gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
-- "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)
Jerome Lambert
helios wrote: (...)
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire sur le steamer il utilise directement les drivers meme chose pour une imprimante il utilise directement le drivers sans passer par linux (linux est juste informe mais non utilise ) lorsque pick creer un users il le creer lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de controles.
C'est un OS, en quelque sorte.
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
helios wrote:
(...)
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire
sur le steamer il utilise directement les drivers meme chose pour une
imprimante il utilise directement le drivers sans passer par linux (linux
est juste informe mais non utilise ) lorsque pick creer un users il le creer
lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de
controles.
C'est un OS, en quelque sorte.
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
exemple pour faire ses sauvegardes pick ne passe pas par linux pour ecrire sur le steamer il utilise directement les drivers meme chose pour une imprimante il utilise directement le drivers sans passer par linux (linux est juste informe mais non utilise ) lorsque pick creer un users il le creer lui meme comme linux le ferait mais sans passer par linux
Il prend le controle de la carte SCSI ? et envoie lui meme les codes de controles.
C'est un OS, en quelque sorte.
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Stephane TOUGARD
Jerome Lambert wrote:
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
-- 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
Jerome Lambert wrote:
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi
j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser
un bon vieux Shell et si vraiment on veux gerer des grosses tables en
mode clef valeurs (c'est quand meme vachement basique comme principe),
on db-berckeley, au mieux il y a une API Perl.
--
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
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
-- 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
OoO En ce début d'après-midi ensoleillé du lundi 25 juillet 2005, vers 15:32, "helios" disait:
un system pick est au niveau du noyau du system c'est pour cela qu'il a besoin d'etre root et c'est ce qui le rend performant car il passes pas par les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur le disque pick ne passe pas par les interfaces c'est lui qui geres les interfaces quand il est lance
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. -- les seuls qui lisent les FAQs sont ceux qui savent déjà ce qu'il y a dedans. -+- AT in: Guide du Cabaliste Usenet - chapitre 4 -+-
OoO En ce début d'après-midi ensoleillé du lundi 25 juillet 2005, vers
15:32, "helios" <helios@com02.com> disait:
un system pick est au niveau du noyau du system c'est pour cela qu'il a
besoin d'etre root et c'est ce qui le rend performant car il passes pas par
les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui
sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur
le disque pick ne passe pas par les interfaces c'est lui qui geres les
interfaces quand il est lance
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait,
ça commence au niveau 1.
--
les seuls qui lisent les FAQs sont ceux qui savent déjà ce qu'il
y a dedans.
-+- AT in: Guide du Cabaliste Usenet - chapitre 4 -+-
OoO En ce début d'après-midi ensoleillé du lundi 25 juillet 2005, vers 15:32, "helios" disait:
un system pick est au niveau du noyau du system c'est pour cela qu'il a besoin d'etre root et c'est ce qui le rend performant car il passes pas par les surcouches ISO il est sur le niveau 0 contrairement au autre SGBD qui sont en niveau 5 ou 6 (niveau 7 c'est l'utilisateur) pour ecrire ou lire sur le disque pick ne passe pas par les interfaces c'est lui qui geres les interfaces quand il est lance
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. -- les seuls qui lisent les FAQs sont ceux qui savent déjà ce qu'il y a dedans. -+- AT in: Guide du Cabaliste Usenet - chapitre 4 -+-
helios
"Stephane TOUGARD" a écrit dans le message de news:
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.
pour avoir un acces en local il faut que tu soit sur le poste administration
du serveur donc en general l'administrateur a le mot de passe root
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
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote toto crack le remote il se trouve sous linux user toto avec les droit toto et ne peut pas en sortir il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de titi
2/ sous oracle j'ai l'user toto en remote toto crack le remote toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout les users d'oracle donc titi
conclusion pick est bien plus securise car il faut cracker tout le system pour acceder a un autre utilisateur de la sgbd
-- 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" <stephane@unices.org> a écrit dans le message de
news:bd3fr2-tek.ln1@gulliver.unices.org...
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.
pour avoir un acces en local il faut que tu soit sur le poste administration
du serveur donc en general l'administrateur a le mot de passe root
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
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote
toto crack le remote
il se trouve sous linux user toto avec les droit toto et ne peut pas en
sortir
il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de
titi
2/ sous oracle j'ai l'user toto en remote
toto crack le remote
toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout
les users d'oracle donc titi
conclusion pick est bien plus securise car il faut cracker tout le system
pour acceder a un autre utilisateur de la sgbd
--
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" a écrit dans le message de news:
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.
pour avoir un acces en local il faut que tu soit sur le poste administration
du serveur donc en general l'administrateur a le mot de passe root
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
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote toto crack le remote il se trouve sous linux user toto avec les droit toto et ne peut pas en sortir il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de titi
2/ sous oracle j'ai l'user toto en remote toto crack le remote toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout les users d'oracle donc titi
conclusion pick est bien plus securise car il faut cracker tout le system pour acceder a un autre utilisateur de la sgbd
-- 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 Zuckerman
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
-- "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)
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait,
ça commence au niveau 1.
Je pense qu'il parlait des runlevels de Linux (en System V)
--
"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)
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
-- "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)
helios
"Stephane TOUGARD" a écrit dans le message de news:
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).
il suffit de cracker le remote pour avoir acces a tout les utilisateur du sgbd
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au moins.
la serrure lanborguini est plus complexe et donne access a plus de chose
(une lamborguini entre autre) par contre la serrure 2cv ferme mais il suffit d'avoir les clef de n'importe quel 2cv pour l'ouvrir donc tres facile a voler car une fois que tu as une clef de 2cv tu as access a toute les 2cv a ton avis un voleur de voiture choisiras quoi voler avec enormement de difficulte et de risque une lanborguini ou pouvoir voler toute les 2cv sans aucun problem ni risque puisque une fois qu'il a les clef d'une 2cv il peut toute les ouvrir et demarer (la 2cv 1937 n'avait pas de neiman, ni demareur d'ailleur)
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees dans pick l'acces au donne est segmente en cas de crack dans un sgbd le crack d'un users donne acces au donne de tous
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:vi1fr2-77k.ln1@gulliver.unices.org...
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).
il suffit de cracker le remote pour avoir acces a tout les utilisateur du
sgbd
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au
moins.
la serrure lanborguini est plus complexe et donne access a plus de chose
(une lamborguini entre autre)
par contre la serrure 2cv ferme mais il suffit d'avoir les clef de n'importe
quel 2cv pour l'ouvrir donc tres facile a voler car une fois que tu as une
clef de 2cv tu as access a toute les 2cv
a ton avis un voleur de voiture choisiras quoi voler avec enormement de
difficulte et de risque une lanborguini ou pouvoir voler toute les 2cv sans
aucun problem ni risque puisque une fois qu'il a les clef d'une 2cv il peut
toute les ouvrir et demarer (la 2cv 1937 n'avait pas de neiman, ni demareur
d'ailleur)
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees
dans pick l'acces au donne est segmente en cas de crack dans un sgbd le
crack d'un users donne acces au donne de tous
"Stephane TOUGARD" a écrit dans le message de news:
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).
il suffit de cracker le remote pour avoir acces a tout les utilisateur du sgbd
Donc, peut etre que c'est une 2CV, mais les portes ferment a clef au moins.
la serrure lanborguini est plus complexe et donne access a plus de chose
(une lamborguini entre autre) par contre la serrure 2cv ferme mais il suffit d'avoir les clef de n'importe quel 2cv pour l'ouvrir donc tres facile a voler car une fois que tu as une clef de 2cv tu as access a toute les 2cv a ton avis un voleur de voiture choisiras quoi voler avec enormement de difficulte et de risque une lanborguini ou pouvoir voler toute les 2cv sans aucun problem ni risque puisque une fois qu'il a les clef d'une 2cv il peut toute les ouvrir et demarer (la 2cv 1937 n'avait pas de neiman, ni demareur d'ailleur)
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees dans pick l'acces au donne est segmente en cas de crack dans un sgbd le crack d'un users donne acces au donne de tous
