Je crois que c'est, au contraire, une bonne idée. Après tout, le nom de l'utilisateur est la moitié des informations nécessaires pour accéder un à système.
Bien que je ne changerai pas, de moi-même, le nom de l'uid0 sur une machine qui ne contiens que des informations de faible importance, je pense que je serais fortement tenté de le faire si je sais que la machine en question contiens des informations de haute sécurité. Après… j'avoue, je n'y connais rien en sécurité, je ne suis pas admin.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Justement, c'est cela qui m'intrigue. Linux est considéré comme un fils spirituel d'UNIX (mais moins que les BSD je crois?)
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
on constate une vérification hard-codée dans mount?
En fait, il y a une raison à cela : si tu écris « ls -l $(which mount) », tu t'apercevras que mount a le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).
Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
et le doute m'entraîne à poser des questions, pour comprendre pourquoi les choses que je crois être des erreurs en sont vraiment.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Tu serais donc encore plus horrifié que moi en voyans la façon de… hum… travailler…. de la boîte pour laquelle je bosse. Déjà, on demande à des dev d'être admin de serveurs critiques, en plus, on nous demande de déployer des cibles de test sur les serveurs de prod, et, je te le promets à ma grande honte, il n'y à qu'un seul compte sur ces machines: root. J'y suis depuis presque un an, j'ai toujours râlé et gueulé contre cet état de fait (je ne te parle même pas de l'architecture… ou du manque de… des… logiciels… pissés!
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
erk… ceci dit, j'essaie de réduire la cata… utiliser un CVS et un bugtracker, monter un serveur avec des VM pour le test, et je n'ose imaginer faire un buildbot avec tests unitaires, j'ai déjà assez de résistance au changement comme ça!)
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
Je crois que c'est cette partie là que je ne comprend pas, en fait. Je pense qu'il me faut étudier les effets exacts de ce flag, il n'y à qu'ainsi que je pourrais comprendre pourquoi on teste si le lanceur à l'uid 0 dans mount pour certaines conditions.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
Au fait, j'ai soudain un doute en te relisant : On rappelle que l'utilisateur ayant l'ID 0 est le root, tout simplement.
Dans l'absolu, on pourrait aussi changer le nom de login du root même si c'est une mauvaise idée, mais l'utilisateur ayant l'identifiant nul reste la définition du super-utilisateur, à tous les niveaux du noyau.
Il est utile de rappeler également que — en principe — la philosophie UNIX est « tout est fichier ». Il y a donc d'un côté le super-utilisateur qui a tous les pouvoirs (Dieu sur Terre) et, de l'autre, les utilisateurs ordinaires. Par le biais des bits setuid dans un certaine mesure et surtout des différents droits d'accès, notamment sur les fichiers spéciaux, on peut gérer les privilèges accordés aux différents utilisateurs de façon simple et unifiée, sans que cela fasse l'objet de niveaux prédéterminés comme on en trouvait sous Windows à l'époque (avec les powerusers, admin, etc.).
Ça veut dire que d'une part, tout ce qui peut tourner dans l'espace d'un processus sans avoir la possibilité de perturber ceux des autres utilisateurs peut s'exécuter en mode non privilégié. Autrement, il faudra avoir le droit de le faire.
Ça signifie aussi que « root » n'est pas un utilisateur ordinaire : même l'administrateur d'un site ou celui de sa propre machine ne travaille jamais en root. Il utilise un compte ordinaire auquel il accorde quelques droits pour le travail au quotidien et ne passe root que ponctuellement lorsque c'est nécessaire.
Le bit setuid est également un bon moyen de faire passer automatiquement un processus en root (ou autre identité) tout en limitant ce privilège à l'exécutable de la commande lancée : ça va être le cas de passwd, par exemple, puisque c'est nécessaire pour pouvoir modifier le fichier central lorsque l'on change de mot de passe. C'est également le cas de mount, qui permet à tout un chacun de monter à loisir ce qui se trouve déjà dans /etc/fstab, pourvu que la ligne concernée soit munie de l'attribut "user" ou "users".
cela ne changerait pas le fait que l'accès au montage serait sécurisé (seuls les utilisateurs appartenant au groupe disk peuvent monter un périphérique)
Ce n'est pas une constante gravée dans le marbre : un simple chgrp/chmod suffit à changer cet état de fait et il faut vérfier cela pour chacun des périphériques spéciaux, un par un.
avec en plus le bénéfice pour un utilisateur d'être capable de monter ses iso (chose que l'on peut faire en utilisant fuse, je sais) car étant propriétaire de ses fichiers sans devoir passer par su ou sudo (que je considère comme un workaround, personnellement)
N'oublie pas qu'UNIX est un système multi-utilisateurs : « mount » ne fait pas simplement qu'accéder au périphérique concerné, il construit également un morceau du système de fichiers entier avec. Un fois une partition montée, elle est visible par tout le système et par tous les utilisateurs, même si sa consultation peut être restreinte par des droits d'accès.
Imagine que quelqu'un ait la bonne idée de faire un mount sur /usr/bin (ce qui est parfaitement légal) par exemple : ceci masquerait la quasi-totalité des binaires du système, qui deviendrait automatiquement inutilisable, à moins d'avoir pensé à garder « umount » sur une partie visible du FS.
Tu as l'air d'avoir suffisamment d'expérience pour franchir les premières difficultés qui se présenteront à toi et profiter pleinement du système, mais c'est effectivement beaucoup plus confortable si quelqu'un te prend la main pour te guider.
Il faut aussi savoir qu'en 23 ans, le système a beaucoup évolué. Originellement, c'est un unixoïde mais les nombreux frameworks qu'il fait fonctionner ont suivi une voie propre. Si possible, essaie de te faire présenter les bases du système et la prise en main de la ligne de commande, puis de voir ce qui est proposé individuellement par les différents projets (par exemple, GNOME). Si tu te lances seul, tu risques de te cantonner à ce qui est visible à travers l'interface graphique et rater ce qui fait l'intérêt du système dans sa majeure partie.
Impossible de t'en dire plus avec si peu d'informations mais la meilleure chose à faire dans un premier temps est d'ouvrir un terminal et d'essayer de le lancer depuis là. Au moins, tu auras des messages d'erreur.
Elle a quand même eu le méridien de Paris pendant un temps, ce qui en faisait la moitié du centre du monde si l'on considère que les longitudes s'étendent de -180° à +180°… :-)
Soit ta partition système est vide parce que l'installation s'est mal déroulée, soit le kernel essaie de booter sur la mauvaise partition (possible si l'installation utilise des UUID pour les reconnaître et que ceux-ci ont changé entre temps). « init ».
Un kernel panic, c'est une situation dans laquelle le noyau lui-même ne peut plus continuer à travailler. C'est un peu l'équivalent d'un écran bleu sous Windows, à ceci près que le message d'erreur est généralement plus explicite. Ça peut être dû à des choses sérieuses comme des défaillances matérielles mais en l'occurrence, ça veut juste dire qu'une fois qu'il a démarré complètement, il ne trouve pas le programme « init », qui est en fait le premier des programmes fonctionnant normalement et qui est chargé de lancer proprement tout le reste ensuite.
Appuie sur « e » au démarrage à la place d'entrée en face de « Ubuntu with linux 3.13.0-24-generic » pour voir quelles sont les options passées au noyau. Il faudra peut-être ensuite démarrer avec un LiveCD pour voir si l'installation sur le disque a vraiment échoué ou s'il s'agit d'autre chose.
Il se peut enfin que tu aies des problèmes avec l'UEFI mais je n'ai aucune expérience de ce côté.
Et surtout, quel âge a le portable ? Il a fallu que je recoure à « forcepae » pour pouvoir prolonger la vie d'un Presario X1000 en lui installant une Lubuntu remplaçant une Hardy Heron hors d'âge.
ça revient au même ? La commande cp est plus sexy !
Oui, puisque les fichiers spéciaux /dev/sdxx (et tous les périphériques disque en général) servent à présenter le contenu du disque entier, secteur par secteur et du premier au dernier, comme une grosse image linéaire. C'est l'interface privilégiée entre le kernel, le hardware du disque et l'utilisateur. Ça fonctionne aussi en faisant « cat image.iso > /dev/sd… » mais c'est un UUOC.
Jusqu'à une époque récente, les 512 premiers octets de l'image d'un noyau fraîchement compilé contenaient systématiquement une amorce (au moins sur PC), tant et si bien qu'un « cat bzImage > /dev/fd0 » donnait automatiquement une disquette bootable. En fait, seul le noyau démarrait mais on le configurait pour qu'il embraye de lui-même vers le disque approprié. C'était pratique avec les BIOS un peu capricieux qui ne voulaient pas démarrer sur les disques secondaires, et lorsque l'on écrasait accidentellement le MBR (par exemple, à la suite de l'installation d'un autre système) avant que les LiveCD se généralisent.
« dd » signifie « Disk Dub », et sert donc littéralement à dupliquer les disques. Formellement, il va faire la même chose qu'un « cp », à savoir écrire le contenu d'un fichier dans un autre, mais avec des options supplémentaires comme la possibilité de spécifier des offsets, d'indiquer où il en est, et éventuellement de continuer son travail même s'il rencontre des secteurs défectueux. Mais sa principale raison d'être reste la possibilité de faire des accès calibrés, c'est-à-dire de taille fixe et alignés sur des adresses multiples d'un certain facteur, en principe la taille d'un secteur ou d'un bloc. Normalement, c'est la couche « périphérique bloc » du noyau qui s'occupe de ce travail, mais ça devenait nécessaire quand on utilisait des raw devices.
Effectivement, toute l'astuce va consister à construire des périphériques qui, d'un côté, s'interfacent avec un ordinateur central et, de l'autre, sont capables de piloter des équipements existants.
Pour la lumière, domotique ou pas, il existe déjà les télérupteurs. Il s'agit d'interrupteurs télécommandés qui viennent se placer directement sur le tableau électrique et qui fonctionnent comme des relais bistables. En fermant un circuit, on alimente un électro-aimant qui inverse la position du bouton, qui peut par ailleurs être manipulé à la main depuis le tableau. L'avantage est que tu peux alors mettre autant d'interrupteurs que tu veux dans tes pièces, là où un va-et-vient ordinaire se limite à deux. Du coup, il est très facile d'ajouter en parallèle un relais ou un triac pour obtenir le même effet mais à l'initiative de ta centrale.
Pour le chauffage, la plupart des appareils électriques modernes sont équipés d'un fil pilote, qui en principe se passe dans la même gaine que l'alimentation. Lorsqu'il est utilisé, il permet au minimum de demander à l'appareil de basculer entre deux programmes (formellement jour ou nuit), ainsi que certains modes prédéfinis comme la mise hors-gel ou l'arrêt total : http://www.planete-domotique.com/blog/wp-content/uploads/2012/01/ordre_fil_pilote.jpg
Là encore, ces fils pilotes sont faits pour être gérés par un équipement rudimentaire comme un détecteur d'heures creuses ou un thermostat, mais ils peuvent sans difficulté être exploités par la même centrale.
Ça dépend de ce que tu veux faire. Si tu veux faire cohabiter les deux, il va falloir repartionner le disque, redimensionner les filesystems etc. Ça se fait beaucoup mais ce n'est pas trivial. Si, en revanche, tu te moques complètement de Windows XP et de ce qu'il y a sur le disque (à vérifier quand même), alors tu peux lancer une installation initiale qui effacera tout et utilisera automatiquement la totalité de ton disque.
Tu peux installer Linux depuis une clé USB également, à condition de choisir la distribution appropriée et de bien préparer ta clé.
Enfin, c'est mieux si tu peux avoir accès à Internet pendant l'installation (par câble Ethernet ou par Wifi). La majorité des packages sont rapatriés directement depuis les serveurs de l'éditeur de la distribution que tu auras choisie et les mises à jour pourront se faire également pendant cette phase.
Il explique que bien qu'on lui ait réservé une IP fixe, l'administrateur lui demande quand même de faire en sorte que ce soit le DHCP qui lui attribue, probablement pour pouvoir facilement en changer si le besoin s'en faisait sentir, sans avoir à intervenir sur la configuration d'un serveur tiers.
Il explique également n'avoir aucune confiance dans le serveur DHCP et souhaiter mettre en place une procédure de fallback qui pour s'attribuer soi-même l'IP fixe par défaut si jamais le serveur est parti faire un tour au bistrot.
Fais un « mount | grep " /dev " » pour voir ce qui émule ton /dev mais, en principe, il s'agit d'un système de fichiers virtuel reconstruit à chaque redémarrage.
À mon avis, techniquement, tu peux sans risque flanquer /dev2 aux oubliettes, à condition de bien vérifier qu'il n'y a rien d'autre dedans que ce qui ce se trouve déjà dans le /dev ordinaire. Mais avant de le faire, il faut quand même être certain de savoir ce qui l'a mis ici.
Je pense également que ton « mv / /mnt/backup » n'a rien à voir dans tout cela. Je ne sais pas comment fonctionne Amanda Backup en particulier parce que je ne l'utilise pas, mais il est possible, bien que peu probable, qu'un système de backup quelconque ait voulu restaurer une ancienne copie et ai renommé le répertoire existant parce qu'il existait déjà. Ça paraît douteux quand même. Tu es sûr de ne plus te souvenir d'une opération particulière effectuée le 16 avril ?
Tu peux utiliser le lien « Répondre » en bas de chaque commentaire pour préserver le fil de la discussion.
Pour /dev2, c'est assez étrange. Il n'est pas impossible qu'il s'agisse d'un rootkit, mais c'est un peu voyant tout de même. Le « ls » renvoie la date du 16 avril. Ça te dit quelque chose ?
S'il a une adresse en 82.226.xxx.yyy, c'est qu'il a une Freebox.
C'est effectivement elle qu'il faut re-régler. Il arrive effectivement qu'elle repasse en mode bridge à la suite d'une mise à jour qui s'est mal passée ou si on l'a réinitialisée. Il faudrait connaître le modèle de sa boîte pour savoir s'il doit faire cela à travers sa console de gestion (jusqu'à la V5) ou intervenir directement sur la boîte.
[^] # Re: su -c
Posté par Obsidian . En réponse au message lancer un script en tant qu'un autre utilisateur. Évalué à 2.
Sinon, « sudo -u B script.sh », ça marche aussi, avec son propre mot de passe, à condition d'avoir les bons privilèges.
[^] # Re: Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 5.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
En fait, il y a une raison à cela : si tu écris «
ls -l $(which mount)», tu t'apercevras quemounta le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
[^] # Re: Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 4.
Au fait, j'ai soudain un doute en te relisant : On rappelle que l'utilisateur ayant l'ID 0 est le root, tout simplement.
Dans l'absolu, on pourrait aussi changer le nom de login du root même si c'est une mauvaise idée, mais l'utilisateur ayant l'identifiant nul reste la définition du super-utilisateur, à tous les niveaux du noyau.
Il est utile de rappeler également que — en principe — la philosophie UNIX est « tout est fichier ». Il y a donc d'un côté le super-utilisateur qui a tous les pouvoirs (Dieu sur Terre) et, de l'autre, les utilisateurs ordinaires. Par le biais des bits setuid dans un certaine mesure et surtout des différents droits d'accès, notamment sur les fichiers spéciaux, on peut gérer les privilèges accordés aux différents utilisateurs de façon simple et unifiée, sans que cela fasse l'objet de niveaux prédéterminés comme on en trouvait sous Windows à l'époque (avec les powerusers, admin, etc.).
Ça veut dire que d'une part, tout ce qui peut tourner dans l'espace d'un processus sans avoir la possibilité de perturber ceux des autres utilisateurs peut s'exécuter en mode non privilégié. Autrement, il faudra avoir le droit de le faire.
Ça signifie aussi que « root » n'est pas un utilisateur ordinaire : même l'administrateur d'un site ou celui de sa propre machine ne travaille jamais en root. Il utilise un compte ordinaire auquel il accorde quelques droits pour le travail au quotidien et ne passe root que ponctuellement lorsque c'est nécessaire.
Le bit setuid est également un bon moyen de faire passer automatiquement un processus en root (ou autre identité) tout en limitant ce privilège à l'exécutable de la commande lancée : ça va être le cas de passwd, par exemple, puisque c'est nécessaire pour pouvoir modifier le fichier central lorsque l'on change de mot de passe. C'est également le cas de mount, qui permet à tout un chacun de monter à loisir ce qui se trouve déjà dans /etc/fstab, pourvu que la ligne concernée soit munie de l'attribut "user" ou "users".
# Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 3.
Ce n'est pas une constante gravée dans le marbre : un simple chgrp/chmod suffit à changer cet état de fait et il faut vérfier cela pour chacun des périphériques spéciaux, un par un.
N'oublie pas qu'UNIX est un système multi-utilisateurs : « mount » ne fait pas simplement qu'accéder au périphérique concerné, il construit également un morceau du système de fichiers entier avec. Un fois une partition montée, elle est visible par tout le système et par tous les utilisateurs, même si sa consultation peut être restreinte par des droits d'accès.
Imagine que quelqu'un ait la bonne idée de faire un mount sur /usr/bin (ce qui est parfaitement légal) par exemple : ceci masquerait la quasi-totalité des binaires du système, qui deviendrait automatiquement inutilisable, à moins d'avoir pensé à garder « umount » sur une partie visible du FS.
[^] # Re: En ligne de commande
Posté par Obsidian . En réponse au message Identification port USB. Évalué à 2.
Tu peux aussi essayer « lsusb » et voir s'il apparaît dans la liste.
[^] # Re: prendre les choses dans l'ordre
Posté par Obsidian . En réponse au message Comment installer Linux sur mon ordinateur? . Évalué à 3.
Tu peux également essayer le Linux Distribution Chooser pour te faire une première idée :
http://www.zegeniestudios.net/ldc/index.php?lang=fr
Tu as l'air d'avoir suffisamment d'expérience pour franchir les premières difficultés qui se présenteront à toi et profiter pleinement du système, mais c'est effectivement beaucoup plus confortable si quelqu'un te prend la main pour te guider.
Il faut aussi savoir qu'en 23 ans, le système a beaucoup évolué. Originellement, c'est un unixoïde mais les nombreux frameworks qu'il fait fonctionner ont suivi une voie propre. Si possible, essaie de te faire présenter les bases du système et la prise en main de la ligne de commande, puis de voir ce qui est proposé individuellement par les différents projets (par exemple, GNOME). Si tu te lances seul, tu risques de te cantonner à ce qui est visible à travers l'interface graphique et rater ce qui fait l'intérêt du système dans sa majeure partie.
[^] # Re: arg bash
Posté par Obsidian . En réponse au journal Edition simple de fichiers TS sous Linux. Évalué à 3.
Pour l'affection ? :-)
# Le terminal
Posté par Obsidian . En réponse au message chromium s'ouvre plus. Évalué à 3.
Bonjour,
Impossible de t'en dire plus avec si peu d'informations mais la meilleure chose à faire dans un premier temps est d'ouvrir un terminal et d'essayer de le lancer depuis là. Au moins, tu auras des messages d'erreur.
[^] # Re: erreur de site ?
Posté par Obsidian . En réponse au message Re-compilation carte PCI Altera ADP6x01. Évalué à 2.
Il a surtout ajouté : « Je sais que c'est une carte qui doit être configurée sous linux. Est-ce que quelqu'un pourrait m'aider s'il vous plait. »
La question est : est-ce réellement le cas ? mais il faudra creuser un peu pour le savoir quand même…
[^] # Re: Moi qui croyais suivre un site en français...
Posté par Obsidian . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 5.
Elle a quand même eu le méridien de Paris pendant un temps, ce qui en faisait la moitié du centre du monde si l'on considère que les longitudes s'étendent de -180° à +180°… :-)
[^] # Re: suite pb kernel
Posté par Obsidian . En réponse au message pb "Kernel panic". Évalué à 2.
Réponse courte :
Soit ta partition système est vide parce que l'installation s'est mal déroulée, soit le kernel essaie de booter sur la mauvaise partition (possible si l'installation utilise des UUID pour les reconnaître et que ceux-ci ont changé entre temps). « init ».
Un kernel panic, c'est une situation dans laquelle le noyau lui-même ne peut plus continuer à travailler. C'est un peu l'équivalent d'un écran bleu sous Windows, à ceci près que le message d'erreur est généralement plus explicite. Ça peut être dû à des choses sérieuses comme des défaillances matérielles mais en l'occurrence, ça veut juste dire qu'une fois qu'il a démarré complètement, il ne trouve pas le programme « init », qui est en fait le premier des programmes fonctionnant normalement et qui est chargé de lancer proprement tout le reste ensuite.
Appuie sur « e » au démarrage à la place d'entrée en face de « Ubuntu with linux 3.13.0-24-generic » pour voir quelles sont les options passées au noyau. Il faudra peut-être ensuite démarrer avec un LiveCD pour voir si l'installation sur le disque a vraiment échoué ou s'il s'agit d'autre chose.
Il se peut enfin que tu aies des problèmes avec l'UEFI mais je n'ai aucune expérience de ce côté.
[^] # Re: suite pb kernel
Posté par Obsidian . En réponse au message pb "Kernel panic". Évalué à 2.
Et surtout, quel âge a le portable ? Il a fallu que je recoure à « forcepae » pour pouvoir prolonger la vie d'un Presario X1000 en lui installant une Lubuntu remplaçant une Hardy Heron hors d'âge.
[^] # Re: Clé bootable
Posté par Obsidian . En réponse au message comment formater une clé usb en ext2?. Évalué à 8.
Oui, puisque les fichiers spéciaux /dev/sdxx (et tous les périphériques disque en général) servent à présenter le contenu du disque entier, secteur par secteur et du premier au dernier, comme une grosse image linéaire. C'est l'interface privilégiée entre le kernel, le hardware du disque et l'utilisateur. Ça fonctionne aussi en faisant « cat image.iso > /dev/sd… » mais c'est un UUOC.
Jusqu'à une époque récente, les 512 premiers octets de l'image d'un noyau fraîchement compilé contenaient systématiquement une amorce (au moins sur PC), tant et si bien qu'un « cat bzImage > /dev/fd0 » donnait automatiquement une disquette bootable. En fait, seul le noyau démarrait mais on le configurait pour qu'il embraye de lui-même vers le disque approprié. C'était pratique avec les BIOS un peu capricieux qui ne voulaient pas démarrer sur les disques secondaires, et lorsque l'on écrasait accidentellement le MBR (par exemple, à la suite de l'installation d'un autre système) avant que les LiveCD se généralisent.
« dd » signifie « Disk Dub », et sert donc littéralement à dupliquer les disques. Formellement, il va faire la même chose qu'un « cp », à savoir écrire le contenu d'un fichier dans un autre, mais avec des options supplémentaires comme la possibilité de spécifier des offsets, d'indiquer où il en est, et éventuellement de continuer son travail même s'il rencontre des secteurs défectueux. Mais sa principale raison d'être reste la possibilité de faire des accès calibrés, c'est-à-dire de taille fixe et alignés sur des adresses multiples d'un certain facteur, en principe la taille d'un secteur ou d'un bloc. Normalement, c'est la couche « périphérique bloc » du noyau qui s'occupe de ce travail, mais ça devenait nécessaire quand on utilisait des raw devices.
[^] # Re: Fourmi au rapport (de bug) !
Posté par Obsidian . En réponse au message le partitionnement de mon ordinateur. Évalué à 6.
« … mais il en occupe 3000 fois l'espace disque. »
[^] # Re: Contrôle du chauffage et de la lumière
Posté par Obsidian . En réponse au journal Angharad, mon système de domotique maison. Évalué à 7.
Effectivement, toute l'astuce va consister à construire des périphériques qui, d'un côté, s'interfacent avec un ordinateur central et, de l'autre, sont capables de piloter des équipements existants.
Pour la lumière, domotique ou pas, il existe déjà les télérupteurs. Il s'agit d'interrupteurs télécommandés qui viennent se placer directement sur le tableau électrique et qui fonctionnent comme des relais bistables. En fermant un circuit, on alimente un électro-aimant qui inverse la position du bouton, qui peut par ailleurs être manipulé à la main depuis le tableau. L'avantage est que tu peux alors mettre autant d'interrupteurs que tu veux dans tes pièces, là où un va-et-vient ordinaire se limite à deux. Du coup, il est très facile d'ajouter en parallèle un relais ou un triac pour obtenir le même effet mais à l'initiative de ta centrale.
Pour le chauffage, la plupart des appareils électriques modernes sont équipés d'un fil pilote, qui en principe se passe dans la même gaine que l'alimentation. Lorsqu'il est utilisé, il permet au minimum de demander à l'appareil de basculer entre deux programmes (formellement jour ou nuit), ainsi que certains modes prédéfinis comme la mise hors-gel ou l'arrêt total : http://www.planete-domotique.com/blog/wp-content/uploads/2012/01/ordre_fil_pilote.jpg
Là encore, ces fils pilotes sont faits pour être gérés par un équipement rudimentaire comme un détecteur d'heures creuses ou un thermostat, mais ils peuvent sans difficulté être exploités par la même centrale.
[^] # Re: C'est dredi alors...
Posté par Obsidian . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 5.
Voir même une navette spatiale, en l'occurrence…
# Oui.
Posté par Obsidian . En réponse au message comment installer linux sur pc fixe xp. Évalué à 4.
Bonjour,
Ça dépend de ce que tu veux faire. Si tu veux faire cohabiter les deux, il va falloir repartionner le disque, redimensionner les filesystems etc. Ça se fait beaucoup mais ce n'est pas trivial. Si, en revanche, tu te moques complètement de Windows XP et de ce qu'il y a sur le disque (à vérifier quand même), alors tu peux lancer une installation initiale qui effacera tout et utilisera automatiquement la totalité de ton disque.
Tu peux installer Linux depuis une clé USB également, à condition de choisir la distribution appropriée et de bien préparer ta clé.
Enfin, c'est mieux si tu peux avoir accès à Internet pendant l'installation (par câble Ethernet ou par Wifi). La majorité des packages sont rapatriés directement depuis les serveurs de l'éditeur de la distribution que tu auras choisie et les mises à jour pourront se faire également pendant cette phase.
[^] # Re: Pas tout compris
Posté par Obsidian . En réponse au message ip fallback. Évalué à 5.
Il explique que bien qu'on lui ait réservé une IP fixe, l'administrateur lui demande quand même de faire en sorte que ce soit le DHCP qui lui attribue, probablement pour pouvoir facilement en changer si le besoin s'en faisait sentir, sans avoir à intervenir sur la configuration d'un serveur tiers.
Il explique également n'avoir aucune confiance dans le serveur DHCP et souhaiter mettre en place une procédure de fallback qui pour s'attribuer soi-même l'IP fixe par défaut si jamais le serveur est parti faire un tour au bistrot.
[^] # Re: 50% résolu !
Posté par Obsidian . En réponse au message accès /dev/null et /dev2/null[RESOLU]. Évalué à 3.
Je te suggère un petit coup de chkrootkit quand même. Je pense que ce n'est pas superflu dans ce genre de situation.
[^] # Re: 50% résolu !
Posté par Obsidian . En réponse au message accès /dev/null et /dev2/null[RESOLU]. Évalué à 3.
Fais un «
mount | grep " /dev "» pour voir ce qui émule ton /dev mais, en principe, il s'agit d'un système de fichiers virtuel reconstruit à chaque redémarrage.À mon avis, techniquement, tu peux sans risque flanquer /dev2 aux oubliettes, à condition de bien vérifier qu'il n'y a rien d'autre dedans que ce qui ce se trouve déjà dans le /dev ordinaire. Mais avant de le faire, il faut quand même être certain de savoir ce qui l'a mis ici.
Je pense également que ton « mv / /mnt/backup » n'a rien à voir dans tout cela. Je ne sais pas comment fonctionne Amanda Backup en particulier parce que je ne l'utilise pas, mais il est possible, bien que peu probable, qu'un système de backup quelconque ait voulu restaurer une ancienne copie et ai renommé le répertoire existant parce qu'il existait déjà. Ça paraît douteux quand même. Tu es sûr de ne plus te souvenir d'une opération particulière effectuée le 16 avril ?
[^] # Re: 50% résolu !
Posté par Obsidian . En réponse au message accès /dev/null et /dev2/null[RESOLU]. Évalué à 2.
Tu peux utiliser le lien « Répondre » en bas de chaque commentaire pour préserver le fil de la discussion.
Pour /dev2, c'est assez étrange. Il n'est pas impossible qu'il s'agisse d'un rootkit, mais c'est un peu voyant tout de même. Le « ls » renvoie la date du 16 avril. Ça te dit quelque chose ?
# Curieux.
Posté par Obsidian . En réponse au message accès /dev/null et /dev2/null[RESOLU]. Évalué à 4. Dernière modification le 21 juillet 2014 à 16:39.
Que donne un « ls -ld /dev /dev2 » ?
Que donne un « getfacl » sur /dev et /dev/null ?
Que donne un « df -h /dev /dev2 » ?
[^] # Re: Quand je vois cela...
Posté par Obsidian . En réponse au journal Le bureau de Linus. Évalué à 3.
En tout cas, on sait maintenant qu'il est déjà prêt pour les tapis roulants…
[^] # Re: Même constats
Posté par Obsidian . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 10.
Mais personne ne sait où… /o\
→[]
[^] # Re: ca ressemble à une connexion du modem en mode bridge
Posté par Obsidian . En réponse au message Obtenir l'IP locale. Évalué à 6.
S'il a une adresse en 82.226.xxx.yyy, c'est qu'il a une Freebox.
C'est effectivement elle qu'il faut re-régler. Il arrive effectivement qu'elle repasse en mode bridge à la suite d'une mise à jour qui s'est mal passée ou si on l'a réinitialisée. Il faudrait connaître le modèle de sa boîte pour savoir s'il doit faire cela à travers sa console de gestion (jusqu'à la V5) ou intervenir directement sur la boîte.