Discuter:UNIX

Un article de Wikipédia, l'encyclopédie libre.

	UNIX fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser.
B	Cet article a été classé comme d'Avancement B selon le Tableau d'évaluation du projet. (Voir les statistiques)
Maximum	Cet article a été classé comme d'Importance maximum selon le Tableau d'évaluation du projet. (Contester?)

La version actuelle de UNIX a été sélectionnée par le comité de sélection du projet Wikipédia 1.0. En discuter...

	Tâches à accomplir pour UNIX	modifier • suivre • rafraîchir • aide
	Mieux sourcer l'article

je pense qu'il est plus précis de dire que les Unix développés par des grandes marques dont les sources ne sont pas disponibles sont propriétaires que commerciaux, car les Unix libres peuvent aussi ^etre vendus et donc faire l'objet d'une transaction commerciale (comme Mandrake ou RedHat par exemple) nicop 16 sep 2004 à 17:39 (CEST)

Je crois que ça correspond effectivement mieux au vocabulaire courant. Mais si on veut chipoter littéralement, les UNIX libres ont aussi tous un ou des propriétaires. Marc Mongenet 17 sep 2004 à 01:44 (CEST)

Les liens BSD arrivent sur une page d'homonymie au lieu de Berkeley software distribution. En outre BSD est souvent décrit comme "Berkeley software development", cela me paraît erroné. Marc Mongenet 15 avr 2004 à 21:19 (CEST)

Il me semble que BSD a eut les deux significations.... (Jerome)

En cherchant dans Google, on trouve 216 "Berkeley software development", le plus souvent en rapport avec la licence. Contre 21900 "Berkeley software distribution". Bref, en attendant une source plus fiable que Wikipedia ou [1] allant dans le sens de "development", je corrige en "distribution". Marc Mongenet 7 mai 2004 à 12:41 (CEST)

Je pense que c'est mieux effectivement... Il y a aussi "Berkeley System Distribution" qui je crois, fut la première signification, mais mieux vaut s'en tenir à "Berkeley software distribution" --Jerome misc 7 mai 2004 à 15:25 (CEST)

"Berkeley System Distribution" est bien la première et sf err la seule reconnue par les puristes (note : le lien proposé pointe vers le site web de l'université mm) Natmaka 27 août 2005 à 01:58:29 (CEST)

Sommaire

1 Schéma
2 Schéma bis
3 Norme POSIX
4 UNiplexed Information and Computing Service
5 Stations de travail Unix
6 Forces et faiblesses Unix
7 Orthographe
8 Pas de root
9 Proposition de sélection de cet article pour Portail:Informatique

[modifier] Schéma

Je preferais l'ancien…

Dans celui-ci, il manque Mac OS X, le deuxieme UNIX plus utilisé au monde… iLux 2 jul 2005 à 20:42 (CEST)

Ce nouveau diagramme est certes incomplet, mais l'ancien était historiquement faux et il pouvait entrainer les lecteurs à la confusion.
Notement parce que BSD et System V n'ont pas a être séparé de cette manière, parce qu'ils sont liés (Unix System V utilise une grande partie du code de BSD).
De plus, c'est un peu ridicule de représenter Solaris et Linux entre les deux de cette manière là. Solaris 1 est certe basé sur BSD, mais Solaris 2 est une refonte complète basée sur System V Release 4 (qui lui contient du code de Solaris 1 et de BSD).
cf : [2] (il faut reconstituer les différents PDFs...).
Sur le lien il s'agit du diagramme le plus complet que j'ai trouvé, il est "énorme", pour montrer qu'on ne peut pas tout mettre...
CAMPESATO Jean-Baptiste 3 jul 2005 à 19:57 (CEST) Oui, je connais ce diagramme, il y a aussi celui cité en fin d'article qui est très interressant, mais ils ne peuvent ni l'un, ni l'autre trouver leur place dans un article "vulgarisateur". L'ancein était faux, le nouveau incomplet…Que faire ? iLux 4 jul 2005 à 13:50 (CEST)

L'ancien étant faux, on ne peut pas le mettre. Et on ne pourra jamais avoir un diagramme complet : regardez la taille du diagramme COMPLET que j'ai posté dans le message précédent. Je veux bien essayer de faire un diagramme un peu plus complet mais réstant simple. CAMPESATO Jean-Baptiste / camje_lemon 4 jul 2005 à 14:20 (CEST)

[modifier] Schéma bis

Hello,
Le schéma ajouté comporte des erreures:

"SRV5" semble être une coquille l'auteur voulait surement parler d'Unix System V (on parle de SVR4 pour Unix System V Release 4 par exemple, et la Release 5 est connu sous le nom d'UnixWare 7 de SCO)
Il faudrait mieu marquer la différence entre Unix Time Sharing System de Bell Labs et Unix System d'AT&T. Du moins montrer l'évolution d'Unix Time-Sharing System (Qui est "l'Unix").
Sur le schéma System V est temporellement parallèle a BSD, or System V date de 1983 et 1BSD de 1978. A plusieurs reprises, du code appartenant à BSD a été implémenté au sein d'Unix System V.
On écrit "Projecte GNU" uniquement en Catalan.
Certaines dates ne correspondent pas.
Stanford University Network c'était le nom que portait le groupe à Stanford (l'université), qui est different de celui de la société

Au lieu de détailler 35ans sur 5cm (impossible sur un petit schéma) d'écran je mettrai en avant les liens de parentés.

Je vous conseille de regarder: http://minnie.tuhs.org/Unix_History/

CAMPESATO Jean-Baptiste / camje_lemon 19 août 2005 à 01:54 (CEST)

Bonjour,
Je viens de modifier le schéma.
CAMPESATO Jean-Baptiste / camje_lemon 19 août 2005 à 18:48 (CEST)

Salut, Excuse si je suis lourd, je ne suis cet article que depuis 2 jours, mais le précédent schéma montrait les principaux Unix propriétaires, alors qu'à lire celui-ci, on pourrait croire qu'il n'y a que Sun... Autre chose : pourquoi le schéma est-il 2 fois dans l'article, une fois en thumb et une fois en grand ? --Cro-Maat 19 août 2005 à 20:15 (CEST)

L'ancien schéma était déjà en double, j'ai donc laissé en double.
Et le schéma courant ne fait allusion que 3fois a Sun...
SunOS 1.0, Solaris 2 et Solaris 10.
Dans mon Schéma j'ai essayé de mettre les OS qui ont le plus joué pour l'histoire d'UNIX.
Et l'ancien schéma comportait des erreurs et était moins net au niveau des liens de parentés.
CAMPESATO Jean-Baptiste / camje_lemon 19 août 2005 à 21:55 (CEST)

Mon opinion est que le schéma n'est pas complet sans AIX, HP-UX, SCO (beurk), IRIX, etc... Avant de voir ce schéma je ne savais même pas qu'il y avait des versions d'Unix qui s'appelaient Unix temps partagé ;-) Je ne veux pas dire qu'il faut les retirer, juste que si le schéma ne comporte pas les trucs que tout le monde connaît, il y a un truc qui cloche... Pour le coup du schéma en double, je pense qu'il serait opportun de corriger ce problème, mais à toi de voir. En effet, ce n'est pas parce qu'un problème dans un article est ancien qu'il cesse d'être un problème ;-)) --Cro-Maat 19 août 2005 à 22:09 (CEST)

Re :)
Unix TimeSharing System est "L'UNIX". C'est l'unix développé par Ken Thompson, puis par l'équipe Unix de Bell Labs. C'est le premier Unix, celui qui est à la base de tout ce qu'on peut voir sur l'article. Cette information est donc plus vitale que AIX, HP-UX, SCO, IRIX:

AIX, HP-UX et UnixWare sont des Unix commerciaux récents, tous basés sur Unix System V Release 4 et n'ont par conséquent joué aucun rôle dans l'histoire d'Unix.

J'ai priviligié les systèmes qui ont été determinant dans l'évolution des Unix.
PS:Il y a bien SCO sur le schéma, avec UnixWare.
CAMPESATO Jean-Baptiste / camje_lemon 19 août 2005 à 23:50 (CEST)

Linux non plus, n'a pas joué, et pourtant il y est, par contre, il n'y a pas Mac OS X (mais NeXTSTEP et OPENSTEP y sont) iLux 20 août 2005 à 15:00 (CEST)

Au début je ne souhaitais pas mettre Linux, mais vu que Linux est assez populaire je l'ai mis. Cependant NeXTSTEP et OPENSTEP ne sont pas sur le diagramme ôÔ.
CAMPESATO Jean-Baptiste / camje_lemon 20 août 2005 à 16:52 (CEST)

Effectivement, il n'y a pas NeXTSTEP. C'est pourtant le premier UNIX à avoir eu une interface graphique, on peut dire qu'il a conté… Quand à Linux…Mac OS X est très populaire, aussi…iLux 20 août 2005 à 18:43 (CEST)

NeXTstep n'est pas le premier UNIX a avoir inclu une interface graphique. NeXTstep 1.0 est sorti en 1988. X11 a été créé par le MIT en 1984 en concurrence avec SunView qui équipait les Sun-2 sous SunOS depuis 1984. En 1987, Sun sorti XView, une version plus moderne de SunView, et NeWS un serveur graphique vectoriel, rapidement abandonné au profit de X11.
Puis je ne vois pas en quoi l'interface graphique a jouer dans l'histoire d'UNIX, la on est dans un autre conte.
Et Linux est plus utilisé que Mac OS X.
CAMPESATO Jean-Baptiste / camje_lemon 20 août 2005 à 20:42 (CEST)

Non, NeXTSTEP est le premier à avoir "une" interface graphique, partie intégrante du systeme, et non aisément portable… Quant à OSX, il est plus utilisé que Solaris… Et OSX PPC et deuxieme systeme d'exploitation le plus utilisé au monde, derriere Windows x86, et devant Linux x86

Je ne vois pas ce que tu entends par ""une" interface graphique, partie intégrante du systeme, et non aisément portable?", SunView, puis NeWS et XView sont les interfaces graphiques de SunOS au même titre que celle qui était utilisé sous NeXTstep.
D'après des statistiques plus ou moins fiables, en tennant compte de la fréquence de sortie des distributions, on compte jusqu'en 2004 le nombre de distributions Linux vendues supérieures aux ventes de Macintosh et Mac OS X. En outre, on estime le nombre d'utilisateurs Linux incroyablement plus élevé que le nombre de boites vendues, due à la disponibilité en téléchargement de ces produits.
CAMPESATO Jean-Baptiste / camje_lemon 21 août 2005 à 13:02 (CEST)

Je veux dire que SunOS et Solaris ont d'abord été developpé en mode texte, puis en graphique. NeXTSTEP, non iLux 21 août 2005 à 13:59 (CEST)

Il est tout à fait correct que la première version de NeXTstep en 1988 disposait d'une interface graphique, mais je ne vois pas du tout ou tu veux en venir. SunOS disposait d'une interface graphique depuis 4 ans auparavent, et c'est sans doute pas le seul UNIX.
CAMPESATO Jean-Baptiste / camje_lemon 21 août 2005 à 14:43 (CEST)

quelle source sérieuse affirme 'Et OSX PPC et deuxieme systeme d'exploitation le plus utilisé au monde, derriere Windows x86, et devant Linux x86' ? c'est p-e vrai sur le seul poste de travail ms il faut en ce cas le préciser Natmaka 27 août 2005 à 01:58:29 (CEST)

Je n'ai effectivement pas été très précis, je ne parles pas ici de mainframes, ni d'ordinateurs à utilisation industriels…Je cherche la source, et vous la poste ici-même sous peu. De plus de nombreux utilisateurs utilisent Linux et Windows en double boot. Donc, ils comptent double, cela signifie bien que le nombre d'ordinateurs sous Linux est très peu fiable, car il n'est pas possible de compter avec précision le nombre de machines bootant régulierement sous Linux iLux 27 août 2005 à 14:57 (CEST)

[modifier] Norme POSIX

«Les UNIX sont aujourd'hui tous conformes à la norme POSIX.» C'est vrai ou en partie ? Ayadho 26 septembre 2005 à 14:02 (CEST)

A ma connaissance ceci est faux. Tous les Un*x (Linux compris), sont plus ou moins compatibles : ils le sont en général sur la plupart des recommandations mais pas sur toutes. Iznogoud 26 septembre 2005 à 16:21 (CEST)

C'est ce qui me semblait (j'ai également entendu que la norme est assez volumineuse), l'ennui c'est que je n'ai pas trouvé d'informations pertinentes pour pouvoir modifier avec raison et élégance. Il faut dire aussi que je n'ai pas cherché des masses. J'ai lu dans le forum d'un article du site Libre-Fan qu'on n'aurait pas passé les tests de validation de la norme POSIX, mais le contraire est affirmé dans cet article.

Je me souviens bien de l'époque ou Bill CLinton avait lancé la certification POSIX de Linux, et la manièere dont M$ avait (discretment, ou presque) de l'en empécher~ιλϒᵡ~ 26 septembre 2005 à 20:02 (CEST)

Pour information: seul deux OS sont reconnus "POSIX03-Compliant" par l'OpenGroup (http://www.opengroup.org/openbrand/register/) il s'agit d'AIX et de Solaris. Toujours dans ce même lien on remarque que Linux n'a jamais été attesté dans une des normes de l'OpenGroup.
Il est amusant de noter que l'OpenGroup arrive en 1996 et que les Unix originaux des Bell Labs ne sont pas compatibles POSIX ;). De plus Unix Time-Sharing System 8 "corrigeaient" certaines "erreures/inutilités" de 4.1BSD (Le travail de BSD étant apprécié par les laboratoires Bell.), et ces corrections ne sont pas appliquées à la norme POSIX, ce qui fait que par exemple on retrouve l'option -u à cat dans POSIX. POSIX n'est donc pas parfait non plus. (cf http://gaul.org/files/cat_-v_considered_harmful.html). Au travers de ceci je tenais à montrer que dire qu'un OS est UNIX que s'il est POSIX n'est pas une idée forcément vraie, on ne peut pas dire que les UNIX originaux ne sont pas des UNIX et autres; En théorie je dirai que POSIX est juste une norme pour pouvoir travailler sur plusieurs systèmes différents de manière transparente.
Je pense qu'il faudrait donc revoir la remarque «Les UNIX sont aujourd'hui tous conformes à la norme POSIX.»
CAMPESATO Jean-Baptiste / camje_lemon 29 octobre 2005 à 00:58 (CEST).

Bravo (et merci) pour ces précisions, j'ai modifié la phrase en conséquence. Iznogoud 31 octobre 2005 à 12:03 (CET)

Pour aller dans le sens de ce qui a été dit, je rajoutterais que certaine version de windows (NT4 ? ou 2000) était certifié Posix, et pourtant, je doute que personne ne soutienne que windows est un unix. Mkende 8 janvier 2005 à 22:32 (CET)

[modifier] UNiplexed Information and Computing Service

Bonjour,
J'ai lu dans l'article qu'Unics signifiait UNiplexed Information and Computing Service, or Brian Kernighan dit avoir proposé Unics sur un jeu de mot avec Multics:
"Multi car MULTICS fait des choses de plusieurs façons différentes, et Uni car Unics fait chaque chose d'une seule façon" (afin de faire ressortir la simplicité qui régit la "philosophie Unix") et ne parle pas de cet acronyme, d'ailleurs à la base "UNIX" était en minuscule (Unix, donc pas d'acronyme) mais AT&T déposa le nom en majuscule (Peut être, pour faire comme MULTICS) c'est pour cela que maintenant on se doit de dire UNIX, et non a cause d'un certain acronyme.
J'ai donc modifié cette partie du texte (ainsi que le choix du langage pour réécrire UNIX.)
Pour information aucune version ne porte le nom Unics, la version de 1969 sous PDP-7 se nomme "New Ken's System" et la première édition en 1971 se nomme Unix Time-Sharing System 1 pour montrer qu'il s'agit d'un système multi-tâche et multi-utilisateur (Unix en minuscules par contre, car Unix est le nom choisit par les développeurs Bell Labs et Unix Time Sharing System n'est pas un produit commercial d'AT&T).
Cordialement,
CAMPESATO Jean-Baptiste / camje_lemon 3 novembre 2005 à 20:09 (CET).

Unix est également un très mauvais jeu de mot avec Eunuchs (eunuques). Schtong 30 août 2006 à 18:12 (CEST)

[modifier] Stations de travail Unix

Je ne vois pas du tout l'intérêt de cette section.

D'une part, elle n'apporte pas grand chose à la présentation du système Unix ; on pourrait envisager d'en mettre une version allégée et améliorée plus bas dans le texte, eu égard à la place que ce type de machines a eu dans l'évolution d'UNIX au cours des années 85-95.

D'autre part, l'essentiel du texte est constitué d'opinions ou appréciations très personnelles et contestables.

Marc 1 février 2006 à 17:26 (CET)

Je trouve également que ce passage d'une part ne traite pas le sujet qu'il annonce mais est surtout très discutable du point de vue de son objectivité. Le monde UNIX ayant été longtemps réservé au cadre industriel et de recherche est très normalisé, je vois donc difficilement en quoi l'interropérabilité et la contre-productivité ont a en souffrir, et surtout en quoi le "déclin" y est lié; argument supporté par le fait que le message de conclusion est biaisé (voire diffamatoire) Linux serait plus interropérable... avec lui-même ? Il me semble que le critère de "coût" est prédominant... et a été quelque peu occulté au profit d'une interprétation "large" des faits...

--Jollyd 20 novembre 2007 à 22:10 (CET)

[modifier] Forces et faiblesses Unix

Que penseriez vous de l'ajout d'une section forces et faiblesses d'Unix ?

Car il y'aurait à dire tant dans l'une que l'autre de ces catégories, si elles voyaient le jour.

Ça n'aurait pas beaucoup de sens, vu qu'UNIX est une notion tellement large (que chacun comprend comme il veut) et tellement étendue dans le temps qu'il est dur d'unifier des pours et des contre. Les avantages et inconvénients d'IRIX ne sont pas les mêmes que ceux de Mac OS X qui ne sont pas les même que ceux de Linux qui ne sont pas les mêmes que ceux de Plan 9 (je parles là d'UNIX au sens très large)… ~ιλϒᵡ~ 5 janvier 2007 à 22:36 (CET)

[modifier] Orthographe

Apparemment, c'est très tendance chez les informaticiens en ce moment de mettre "ces" pour le pluriel d'un mot se terminant en x. Ça n'a aucune validité en français, mais j'imagine que si je corrige ça sans prévenir, ça ne passera pas. Je ne vois pas trop quoi faire, tenter d'endiguer ce retour au source latine par l'intermédiaire d'un anglicisme pour empêcher que le français ne devienne davantage complexe/riche ? ;) lejocelyn

[modifier] Pas de root

root (qui est d'ailleurs désactivé par défaut)

Qu'est-ce que c'est censé vouloir dire ?

Comment peut-on désactiver un utilisateur ?

--Wcorrector (d) 28 novembre 2007 à 22:24 (CET)

chmod -rwx user:user

? Ça devrait marcher :)

Plus sérieusement, on peut désactiver un compte pour le rendre inopérant (càd retirer ses droits) au lieu de le supprimer.

Pour ce qui est de la phrase, il faut la reprendre dans le contexte: Mac OS X permet d'installer des applications et d'intervenir sur la configuration du système au moyen d'un compte administrateur distinct de root (qui est d'ailleurs désactivé par défaut), en ce qu'il ne peut modifier les fichiers fondamentaux du système.

Je comprend par là (je ne suis pas un expert Mac :) que sous Mac, il y a 2 comptes d'administration pour 2 niveaux d'administration: un pour l'installation/configuration courante et un autre root pour ce qui touche à l'installation, la ré-installation, la configuration fondamentale (noyau...) qui, lui, est réservé aux experts. On pourrait mieux reformuler la phrase certainement... Romainhk (QTx10) 30 novembre 2007 à 01:07 (CET)

Je ne comprends nullement. Quel est l'effet de chmod -rwx user:user ?

Bien sûr, les paquetages installés n'ont pas tous besoin d'appartenir à root (sauf, logiquement, ceux dans le $PATH de root); ils peuvent appartenir à 'administrateur'. C'est très utile, en fait : cela permet de déléguer l'installation et la gestion des programmes à des utilisateurs de confiance sans leur donner accès au périphériques, au noyau, aux fichiers appartenant à root en général; cela ne leur donne pas directement accès aux comptes utilisateurs (mais je disgresse).

Ceci déconcentre (ou décentralise) un peu la gestion d'Un*x, qui fait trop souvent appel à root (pourquoi faut-il être root pour créer un groupe ? Est-ce une opération 'sensible' ?).

En général, on peut créer des échelons intermédiaires, des domaines cloisonnés : soit simplement en créant un utilisateur spécifique pour effectuer certaines actions (méthode Postfix), soit carrément en chroot (et utilisateur spécifique aussi, sinon ça sert à rien).

Avec le chroot-jail de grsecurity ou d'OpenBSD on peut carrément faire des root dans un sous-environnement. Avec la virtualisation on peut avoir un système complet dans un autre. Tout ceci ne fait que créer de nouveaux root, Princes en leur domaine (qui est restreint). Cela ne supprime ni ne diminue les droits de root (en son domaine, toujours).

J'ai lu dans des magazines informatiques (je me suis repenti d'en avoir acheté) que certains systèmes (logiciels) restreignent les droits de root. Cela me parait totalement absurde et contradictoire.

Pour en revenir à nos moutons, qui sont Un*xiens : en Unix traditionnel, l'utilisateur root est par définition celui d'ID 0. Le système donne des droits particuliers aux processus d'EUID 0 (par exemple le fait d'ignorer les permissions). linux modifie le système avec les capabilities mais ça revient le plus souvent au même (et beaucoup d'administrateurs de PC ne connaissent pas la différence) : se loguer sous root donne automatiquement toutes les capabilities. Sous linux, être 100% root signifie avoir toutes les capabilities. (Je ne sais où se situent les *BSD dans ce domaine.)

On peut modifier la n'importe-quoi dans les fichiers, la notion de root est programmée dans l'OS : il donne à tous processus ayant certains attributs des droits particuliers, et il démarre le processus initial (init) avec ces attributs. Certaines opérations n'étant possible que pour de tels processus, il faut qu'il bien conserver la possibilité de lancer de tels processus.

--Wcorrector (d) 30 novembre 2007 à 03:21 (CET)

chmod pour change mod permet de modifier les droits d'écriture, de lecture et d'exécutions associés aux fichiers. -rwx veut dire retirer les droits (dans l'ordre) de lecture, d'écriture et d'exécution et user:user indique le nom de l'utilisateur cible (avant les ":") et le groupe cible (après les ":"). Ainsi, l'utilisateur user du groupe user n'a plus aucuns droits sur les fichiers. Je n'ai pas fait le test mais sur le papier, ça à l'air de fonctionner... ;) je commence à avoir des doutes d'ailleurs.

La création de groupe est une opération sensible dans le sens de la sécurité. Si n'importe qui peut créer des groupes, il doit aussi pouvoir changer les droits des fichiers pour associer son nouveau groupe au système de fichiers... et l'accès au changement de droits est critique pour la sécurité.

Mac est connu pour sa convivialité donc je penses que l'accès root ne soit quasiment jamais utile sur ce système. Mais ça ne veut pas n'ont plus dire que le compte root soit réellement désactivé/inopérant... Il peut tout de même fonctionner, lancer l'init, etc... mais c'est son accès par l'utilisateur lambda qui est restreint. L'auteur de la phrase voulait sûrement dire que l'accès en root n'est pas permis par défaut, pour éviter aux non-initiés de faire réellement n'importe quoi.

J'ai trouvé 2 liens qui en parle dans ce sens: http://naxos.biomedicale.univ-paris5.fr/rg/?Root et http://docs.info.apple.com/article.html?artnum=106290-fr

Il faudrait plutôt reformuler la phrase en: Mac OS X permet d'installer des applications et d'intervenir sur la configuration du système au moyen d'un compte administrateur distinct de root (NB: Sous Mac, administrateur est un root restreint; l'utilisation direct du compte root est rare). C'est l'accès au compte qui est restreint et non le compte en lui-même... Romainhk (QTx10) 30 novembre 2007 à 16:03 (CET)

Où ça ? Pas sur Un*x en tous cas. La syntaxe chmod perm user:group n'existe pas, parce que ce que tu veux exprimer n'a pas de sens sur ce genre de systèmes (ceci dit je ne suis pas encore tout à fait sûr d'avoir compris ce que voulais faire).

Ainsi, l'utilisateur user du groupe user n'a plus aucuns droits sur les fichiers.

Mais quels fichiers ?

Je n'ai pas fait le test mais sur le papier, ça à l'air de fonctionner... ;)

Qu'est-ce que ça devrais faire ?

je commence à avoir des doutes d'ailleurs.

Tu fais bien. Parce qu'un utilisateur n'a aucun droit (sauf root, c'est important, voir la suite). Un utilisateur est un sujet (je appris ce terme récemment — merci Wiki). Il peut agir sur des différentes choses dont les fichiers, des processus, et peut être d'autres trucs qui ne viennent pas à l'esprit tout de suite; ces choses sont appelées des objets dans la formalisation du contrôle d'accès.

Chaque objet a un propriétaire, un sujet. Un objet peut avoir des permissions d'accès (par exemple un fichier).

L'important est que dans Un*x, un sujet peut modifier les permissions d'accès d'un fichier (un objet) dont il est propriétaire. Donc on peut toujours essayer de lui sucrer la permission d'accès à ses fichiers, du moment qu'il peut nommer le fichier (qu'il a accès au répertoire) et que tout le système de fichiers n'est pas en lecture seule, l'utilisateur pourra rechanger les permissions de ses fichiers. Quand aux processus, là il n'y a pas de permissions qui tiennent : un utilisateur peut manipuler ses processus comme il l'entend, et nul autre utilisateur ne peut le faire (ce droit n'est pas transférable); un utilisateur peut envoyer un signal (kill -signal PID), donc il peut bloquer (puis débloquer), voir tuer (par la mort qui tue : kill -KILL PID) un de ses processus.

Cette dernière possibilité est particulièrement sensible pour root, puisque des tas de démons très important ont comme propriétaire root.

Enfin n'oublie pas la cas particulier de root, l'utilisateur numéro 0. Par définition, en Un*x, cet utilisateur peut outrepasser tous les contrôles d'accès (disons que c'est immunité diplomatique, ça permet de se sortir de n'importe quoi). Il peut non seulement modifier les permissions de ses fichiers, mais celles des fichiers de n'importe qui. Et il n'a même pas besoin de le faire pour lire ou modifier n'importe quel fichier, parce que les permissions ne s'applique pas à lui. En fait, si un fichier appartient à root, cela a relativement peu d'importance quelles permissions sont définies pour son propriétaire (root), parce que de toutes façons il les contourne toujours, implicitement : il n'a même pas à dire "je veux faire ça et je n'ai pas à suivre la règle générale", il dit juste "je veux modifier ce fichier" et les permissions "lecture-seule" (par exemple) sont ignorées (et il ne peut même pas, dans les Un*x traditionnels, renoncer à ce privilège).

Essayer de censurer les droits de root sur ses fichiers (ou en général) est donc particulièrement absurde.

La création de groupe est une opération sensible dans le sens de la sécurité.

Comme toute modification des permissions d'un fichier par son propriétaire, ou plus ?

Si n'importe qui peut créer des groupes, il doit aussi pouvoir changer les droits des fichiers pour associer son nouveau groupe au système de fichiers...

Tu veux dire pouvoir changer le groupe associé à un fichier lui appartenant :

creatgrp mongroupe # commande hypothétique, permise à tout utilisateur

addusrgrp moncopain mongroupe # idem

chown :mongroupe monfichier # cette commande existe

La commande chown existe déjà. Elle est utilisable par tout utilisateur, sur ses fichiers, et pour les groupes auquel il appartient. Ce sont les commandes pour créer et manipuler un groupe en tant qu'utilisateur qui n'existe pas.

et l'accès au changement de droits est critique pour la sécurité.

Si n'importe qui peut créer un groupe, en quoi ça pose problème ?

Mac est connu pour sa convivialité

C'est du blabla commercial. Chez Apple, la convivialité ça a toujours été de faire dans des fenêtres ce que d'autres font dans des fichiers texte. En pratique c'est souvent synonyme de perte de temps. Et parfois d'une immense perte de temps.

donc je penses que l'accès root ne soit quasiment jamais utile sur ce système.

Il faut bien installer un nouveau système/nouveau noyau parfois. Si par contre on a tout le temps besoin de passer root, il y a peut-être un problème.

Mais ça ne veut pas n'ont plus dire que le compte root soit réellement désactivé/inopérant... Il peut tout de même fonctionner, lancer l'init, etc... mais c'est son accès par l'utilisateur lambda qui est restreint.

Restreint comment ?

L'auteur de la phrase voulait sûrement dire que l'accès en root n'est pas permis par défaut, pour éviter aux non-initiés de faire réellement n'importe quoi.

Donc les non-initiés ne peuvent pas partioner, installer, mettre à jour, réinstaller le système.

Comme expliqué plus haut, ils ne peuvent pas créer de groupes. Ni d'utilisateurs.

Ils font comment ?

J'ai trouvé 2 liens qui en parle dans ce sens: http://naxos.biomedicale.univ-paris5.fr/rg/?Root

Bof :

Sous Mac OS X qui est un système multi-utilisateurs, comme tout système dérivé d’Unix, il y a trois niveaux de droits pour un utilisateur : utilisateur simple, administrateur (celui que vous créez lors de l’installation) et root.

Aucun dérivé d'Unix, n'a, à ma connaissance, trois niveaux de droits.

et http://docs.info.apple.com/article.html?artnum=106290-fr

Aaaahhh.

Après activation de l'utilisateur root, vous devez fermer votre session Mac OS X et en rouvrir une en tant qu'utilisateur root.

AU SECOURS.

Il faudrait définir restreint.

--Wcorrector 1 décembre 2007 à 06:22 (CET)

Ce que je connais d'Unix me vient de GNU/Linux/Debian donc il doit y avoir pas mal de différence, je l'accorde; de plus, tu es le premier Unixien que je rencontre ;). Quant à la commande chmod, c'était plutôt un trait d'humour... qui n'a fait rire que moi :/

Il est vrai qu'il n'y a, stricto senso, que 2 niveaux d'utilisation: utilisateur simple et root, qui forment 2 extrêmes. Mais c'est pour ça qu'on a inventé les Access Control Lists: pour permettre aux utilisateurs simples d'avoir parfois plus de droits, créant ainsi d'autres niveaux d'utilisation implicitement.

Pour le chown, j'entendais par là que l'utilisateur du chown ne doit pas pouvoir faire de changement des droits sur un fichier en dehors de sa juridiction; par exemple, sur un fichier de root (ce qui est somme tout très logique mais mal exprimé de ma part à l'origine).

Tu peux aussi en vouloir au slogan de convivialité de Mac (tout comme celui de Windows) qui n'est que trop réducteur: oui, on n'a pas accès au root donc on ne peut pas toucher aux fondements du système, et quand ça marche pas... et bien ça marche plus du tout! Et je suis entièrement d'accord avec toi pour dire que c'est un slogan très "vendeur" qui réduit l'informatique à une sorte de tamagotchi râleur quand on (ceux qui savent ce que c'est qu'un noyau, qui savent qu'on peut le changer et qui savent le faire = les initiés) sait ce qu'on peut faire d'un ordinateur. Et oui, un non-initié ne peut ni partitionner, ni réinstaller, ni ajouter des utilisateurs, etc. car il ne sait même pas que ça existe... (et j'en rencontre tous les jours :/) et quand il le sait: il change de système pour un unix-like ;)

Mais on perd encore un peu le débat là :) Tu voulais savoir pourquoi le compte root de Mac est limité? D'abord, ce ne sont pas les fichiers du root qui sont limités, mais son accès (son authentification, son login), comme si on avait mis 12 mots de passes différents dessus et 54 petites cases à cocher dans le bon ordre: ça sert à décourager son utilisation (c'est jugé dangereux par les concepteurs de ce genre de systèmes); mais il existe bel et bien.

Par restreint, j'entends soumis à la restriction d'une procédure d'activation. Romainhk (QTx10) 1 décembre 2007 à 11:58 (CET)

[modifier] Proposition de sélection de cet article pour Portail:Informatique

Cet article est proposé pour faire partie de la sélection Wikipédia:Sélection/Informatique. Cette page permet d'afficher aléatoirement un article parmis la sélection sur Portail:Informatique. Les articles sélectionnés représentent la vitrine du projet.

Vous êtes invités à vous exprimer sur la page suivante : Wikipédia:Sélection/Informatique/UNIX. Toutes les remarques d'amélioration sont les bienvenues, mais notez que puisque c'est un vote interne au projet, seuls les votes des participants déjà inscrits sur le projet informatique seront pris en compte. --T (d) 11 décembre 2007 à 13:27 (CET)