Heu... pas dans le cas discuté. Ici, la proportion de code restant de Bruce Perens dans BusyBox semble de l'ordre du pouillème.
Au risque de me faire moinsser encore une fois, je tente une autre explication plus terre à terre.
J'écris un policier fantastique qui ne marche pas. Mon héro JIM retourne au placard.
Quelqu'un que je ne connais pas décide de faire la suite des aventures de JIM en lui adjoignant une coequipière VLADA qui est en fait une vampire.
Il a besoin de ma permission pour écrire cette suite, et je peux y opposer mon droit moral même si j'ai vendu les droits patrimoniaux sur les aventures de JIM.
La série des aventures de JIM et VLADA marche du feu de dieu et l'auteur décide d'écrire un prologue dans lequel il raconte comment VLADA est devenu un vampire.
Bien sur l'histoire se passe au moyen age et n'a rien d'une enquète policière. Son histoire n'a aucun rapport avec rien de ce que j'ai écrit.
Accrochez-vous bien : parcequ'il écrit les aventures de VLADA après que les aventures de JIM et VLADA aient été un succès, il a besoin de ma permission pour écrire les aventures de VLADA. Si il me reste des droits patrimoniaux sur JIM je me peux même prétendre à des droits d'auteurs. Dans tous les cas je peux opposer mes droits moraux à son histoire.
Pourquoi ? Parceque les lecteurs connaissent déjà VLADA, parceque son histoire va profiter de la renommée acquise avec un perso que j'ai créé, parceque dans le cas d'histoire écrites à plusieurs mains (scénarios télé par exemple) c'est la seule solution pour qu'aucun des artistes ne soit lésé etc.
De mon coté je peux écrire autant d'aventure de JIM sans VLADA que je veux. Et ce sans rendre de compte à personne.
Alors maintenant je ne sais pas comment ca marche dans le cas d'un logiciel, et à forciori d'un logiciel en GPL. Mais de façon générale le droit européen en ce qui concerne le logiciel est très proche du droit d'auteur classique.
Impossible d’avoir une résolution d’écran supérieure à 800x600 avec le pilote libre.
Sur les serveurs et sur certaines cartes mères il y a parfois des versions modifiées qui déconnent avec le driver ATI il faut alors forcer le driver Mach64.
Mais bon si c'est une puce montée sur carte mère c'est un poil perdu d'avance.
Non, l'auteur initiale n'a pas plus de droit, il en a autant que les autres, c'est tout.
Oui à part que comme initiateur il peut appliquer son droit moral pour bloquer tous les autres, et qu'aucun des autres ne peut le bloquer à part sur les points qu'ils ont eux mêmes créés. Je considère que c'est un poil plus fort...
Dans le pire des cas, tu changes le nom et la coupe de cheveux du personnage, et l'autre auteur n'aura plus rien dire, pour peu qu'il ne participe pas à la conception des nouvelles œuvres.
Tu peux changer le nom, le lieu, la coupe de cheveux, l'époque et le sexe du héro et t'en prendre plein la gueule quand même. Voir les dizaines de plagiats d'Harry Potter qui ont été renvoyés dans l'oubli.
Il faut pas abuser, je peux très bien parler du mickey de walt disney autant qu'il me plaît sans avoir à verser un centime à qui que ce soit.
Pas vraiment non. Dans le cercle privée oui, pour une critique ou une analyse oui, mais si tu créés une oeuvre (ce qui est un peu le cas qui nous interresse là) dans laquelle Mickey Mouse vient faire de la figuration, même fugitivement, même en arrière plan, même si c'est un truc qui pourrait être pris pour Mickey Mouse de loin dans le brouillard etc. Il est très probable que Walt Disney corp vienne te taper sur l'épaule pour demander au mieux un cheque, au pire que tu retires complètement toute référence à la souris de ton truc sous pretexte que ca nuit à l'image.
l'auteur de l'oeuvre initiale comme l'auteur de l'oeuvre dérivée ont tous les deux un droit moral (évidemment, le second auteur n'a un droit moral que sur l'oeuvre dérivée)
C'est à dire pas grand chose. En tant qu'auteur initial je peux exercer mon droit moral pour bloquer ses histoires, et me mettre à en écrire d'autres sans qu'il ne puisse rien dire du moment que je ne reprend aucun des éléments qu'il a introduit lui même.
il est également interdit de ne pas respecter la paternité de l'auteur subséquent.
Si et seulement si je reprend des éléments signicatifs qui ont été créé par le nouvel auteur. Sinon je fais ce que je veux.
J'ai du mal à comprendre l'envie d'avoir des pilotes proprios sous un OS libre.
C'est à dire que les quelques chipsets graphiques qui sont pleinement supportés par Linux, c'est à dire les matrox G200 et G400, les S3 Virge, les Ati Rage 128 et rage Pro sont un poil anciens.
Tous les autres chipsets, à forciori dans leur version "mobility" deconnent à pleins tubes sous Linux que ce soit avec les pilotes libres ou les pilotes proprios, en 2D ou en 3D, en Xorg ou en framebuffer console.
Attention je ne dis pas qu'il n'y a pas des PC ou des mobiles sous Linux qui ne fonctionnent pas très bien avec des chipsets graphiques modernes. Je dis juste qu'à l'achat d'un portable, a moins d'avoir un pote qui a installé le même portable de la même série avec le même bios, il est impossible de savoir à quel point l'affichage va decconner.
Généralement sur portable on fini avec un driver vesa, ce qui est super pour la 2D/3D/Lecture de film etc.
Curieusement, NVidia, tout propriétaire qu'il soit, est le constructeur qui fait le plus d'effort pour rester à la page avec les évolutions de Linux (le kernel, j'ai pas oublié le GNU/)
Intel et AMD font pas mal d'annonces et de presse release, mais bon ne serait-ce que pour activer les transparences Hard en 2D il faut y aller pendant un moment...
Certes, il y a paternité, mais la paternité est partagée entre tous les contributeurs. Elle n'est pas l'apanage de l'auteur initial.
Je ne sais pas comment ca se passe aux US, ni sur les logiciels. Mais en ce qui concerne le droit d'auteur classique, la paternité EST l'apanage de l'auteur initial.
Par exemple si je créé un personnage que j'apelle bidule, et que ce personnage fait un bide total dans une série/un roman/un film.
Maintenant supposons qu'un autre auteur décide de reprendre mon personnage de bidule pour en faire lui une série/un roman/un film à succès. Le mec a beaucoup plus d'idées que moi, il écrit mieux et il a indiscutablement plus de talent. Cependant le créateur du personnage c'est moi. J'ai droit de regard sur tout ce que fait le nouvel auteur. Je peux exercer mes droits moraux pour empécher que le personnage bidule ne fasse ceci ou celà. Je touche de l'argent à chaque fois que le personnage bidule est mentionné etc.
Vu les précautions prises par Marvel sur les super-héros, et les textes longs comme le bras sur les droits des scénaristes des séries américaines, je me dis que ca doit pas être très différents aux US.
Maintenant, re-mettons tout cela dans la balance... Le vaccin gagne encore, car le rapport bénéfice / risque est toujours positif (même en margeant largement sur le nb d'invidus pré-disposés à avoir des maladies neuro-dégénratives, et sur le nombre dans cette population pourrait connaitre des effets çà long terme).
Pas d'accord.
J'ai entre 25 et 40 ans, je suis en bonne santé, je suis dans une tranche ou la probabilité de sequelles suite à une grippe est grosso-modo égale voire inférieure à la probabilité combiné d'une réaction au vaccin, d'une ineffectivité du vaccin, d'une réaction allergique.
Vu le taux de population contaminée ma probabilité d'avoir déjà été en contact avec le virus, voire de rentrer en contact avec le virus pendant la developpement de la réponse immunitaire est loin d'être négligeable (Je prend le métro, et comme en ce moment il y a grève sur le RER A c'est convivial les trajets).
Pour toute ces raisons, je reste loin du vaccin. Les choses aurait été différente si, comme dans le reste du monde, la vaccination avait pu avoir lieu dans les temps. mais se faire vacciner le 15 décembre pour un virus qui a déjà touché 5 millions de compatriotes ca me parait douteux.
Maintenant c'est mon opinion, et je n'ai rien d'un expert en immunologie.
e problème c'est que si c'est du roaming, l'opérateur n'est au courant que lorsque l'opérateur visité lui envoie les tickets de taxation (et c'est pas du temps réel, loin de là).
C'est pas du temps réel d'accord. mais on a pas mal de cartes 3G dans ma boite, et quand un commercial abuse un peu de l'internet à l'étranger (Israel, Quatar, Canada, US, Brésil etc.) Je suis prévenu dans les 48h avec une option stop ou encore.
J'ai du mal à croire que la taxation, même si elle est passée par la Belgique, ait pu monter à 45 000€ sans que personne ne s'en apperçoive.
jail effectue sa propre sécurité. Ca n'a rien a voir avec la politique de sécurité établis sur le système.
C'est quoi la politique de sécurité effectuée par le système ? La séparation kernel mode/user mode ? Parceque UID/GID c'est les routines file system (au sens large) qui gèrent, SE Linux c'est les routines SE Linux, etc. J'aimerais vraiment comprendre le distinguo que tu fais entre des routines kernel de sécurité avec limitations d'une part et d'autres routines kernel de sécurité avec limitation d'autre part.
SE Linux a rien a voir avec un jail ou un chroot.
C'est un système de virtualisation + cotainers. Il est utilisé différamment certes mais fondamentalement c'est exactement le même principe sous-jacent.
Il n'y a pas d'authentification "se linux"
Alors comment donne-t-il les droits ? Si il n'y pa pas de système qui permette de savoir qui a les droits (ie authentification) que fait SE Linux pour les attribuer ? Il tire au sort ?
N.B il existe plusieurs méthodes d'authentification (je suis (bio-métrie), je connais (mot de passe ou clef), je sais faire (door knocking, sign pad), j'ai fait(élévation de privilèges, réattribution de droit, login tortueux))
De plus, c'est pas moi qui confond en utilisant la partie fixe pour parler de la partie variable hein...
Enfin, tu utilise AC pour account control, (Mandatory?) access control , ... ?
Tu dis que c'est gravissime de connaitre les logins qui ont accès à tel ou tel outil, je réponds que ce n'est plus le cas aujourd'hui. Parceque même si le login est une condition nécessaire, ce n'est plus une condition suffisante (justement à cause de la partie variable comme tu l'appelles). Ceci étant, pour ta gouverne sache que dans environnement de domaine la partie fixe est l'UID pas le login. Sur mes serveur root peut être 0, 514 ou 10000 suivant les cas. Avec le même login et le même mot de passe (bon pour 0 il faut la clef). C'est kerberos/LDAP qui attribue le UID suivant l'authentification...
Quand à AC, c'est l'abrevation de access control. Ca englobe tout ce qui est MAC, ACL, jail, SE Linux etc. Bref tout ce qui est attribution/retraits de droits en plus du couple UID/GID
Donc tes procédures ne sont pas à jour et tu as besoin que le système te tienne par la main pour te dire qui a le droit ou pas.
a) En entreprise c'est pas forcément moi qui ait monté le système/domaine
b) En entreprise je suis pas forcément seul et avec la maitrise absolue sur le système/domaine
c) En entreprise il y a des gens qui vont, qui viennent, qui prennent des vacances qui changent de postes, qui prennent des assitants etc.
d) En entreprise il y a des softs fermés dont le vendeur n'assure pas la maintenance si les utilisateurs n'ont pas tel et tel droits.
Après monter un système tel que M. Truc qui a beoin de faire les taches 1, 2 et 4 mais pas la tache 3 et qui quand il part en vacances a besoin que madame chose fasse les taches 1 et 2 et que monsieur bidule prenne en charge la tache 4 nécessite une gestion complète. Si tu es capable de gérer tout çà de tête, félicitation pour toi (à moins que tu ne bosses dans une petite entreprise, ou une boite ou la sécurité n'est pas primordiale). Personellement je bosse pour de très grands groupes étalés sur plusieurs pays, dont des banques. Le nombre de scripts mis en place qui ne servent qu'à déplacer les fichier du dossier a vers le dossier b en changeant les droits au passage est assez impressionant. Mais si on ne le fait pas on se retrouve avec des effets de bords désagréables de type "machin a besoin de faire la tache 1 et la tache 4 mais il se retrouve également avec les droits pour lire les résultats de la tache 3".
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
Je reprend :
Tu as un domaine, dans ce domaine tu as une forêt d'annuaire LDAP avec des relations de confiance les uns avec les autres ou pas. Ensuite tu as des politiques de sécurité certaines dans le domaine, certaines dans l'annuaire LDAP concernée, certaines dans l'annuaire LDAP de l'utilisateur et enfin certaines sur la machine de l'utilisateur et sur le serveur de l'application. Trouver l'ensemble des utilisateurs capables de lancer telle commande avec tels arguments sur l'ensemble du domaine doit être un problème NP complet je pense.
Bien entendu dans la vraie vie on s'arrange pour que ce soit des groupes locaux qui contiennent des groupes LDAP qui sont à leurs tour inscrit dans des politiques domaines. Ce qui rend la détermination de droits plus simple, mais la possibilité de créer des effets de bords reste élevée.
Dans une boite où j'interviens c'était à peu près ce qui ce passé. Conclusion, maintenant c'est "les sysadmins se déplacent quand vous avez besoin de lancer un truc".
Bonjour, les sysadmin sont à Paris et à Toronto. L'utilisateur est à Singapour. Ah, et il lance ce type d'opération 300 fois par jour. C'est la validation/renouvellement des clefs de confiance tierces, légalement il faut une validation humaine. Il lui faut les droits sur le LDAP. A vous.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
On peut tout faire en langage machine sur une machine Turing Complete. La question est peut on le faire bien, de façon fiable dans un temps raisonnable (ie avant que Mme Chose ait besoin d'autres droits). Pas facile. Ca se fait avec des réseaux de Petri coloré par exemple quand on veut être sur de couvrir tous les cas et tous les effets de bords. Le seul ennui est que quasiment personne n'est capable de formaliser un problème de droits à l'échelle d'une boite internationale avec un réseau de Petri. Donc on pense avoir fait les choses proprement, mais on a pas de preuves (au sens mathématique du terme).
Sur la plupart des machines que j'administre, je peux trouver ça sans trop de problème par contre).
Si tu as du mal a trouver ça, c'est peut être que ta politique de sécurité crains un peu, tu ne crois pas ?
Si tu utilise juste les droits UID/GID ca ne pose pas de problèmes en effet. Mais des fois ca ne suffit pas comme droits.
Quand à ma politique de sécurité ca fait trois année de suite que l'audit "surprise" se termine en 30 minutes avec l'auditeur qui est coupé du réseau et qui est obligé d'appeler pour qu'on le débloque de façon à pouvoir finir ses tests (donc au niveau surprise, plouf)
Et puis si on les a rajouté c'est qu'il y a une raison... et si on les a pas supprimé c'est aussi qu'il y a une raison.
Le problème n'est pas là. Un utilisateur X qui n'a plus besoin de l'application A, doit-il garder les droits sur le répertoire 1 utilisé par l'application A mais aussi par d'autres applications dans certains cas.
Répondre à cette question nécessite de savoir parfaitement ce que fait cet utilisateur et d'avoir une architecture complète et à jour de tous les SI pour savoir si l'utilisation 12 de l'application B ne nécessite pas aussi les droits sur répertoire 1.
De plus il est très fréquents que deux utilisateurs qui ont un répertorie en commun l'utilise pour autre chose que ce qui est prévu pour des raisons pratiques. Donc quand on ferme le répertoire 1 à un des deux utilisateurs ca gueule qu'une tache qui n'a rien à voir ne marche plus. Des fois quand c'est un grand ponte qui gueule (Forex ou Trésorerie par exemple) tu recois l'ordre de rendre le répertoire à l'utilisateur qui ne devrait plus en avoir besoin.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Je ne connais pas grand monde qui soit capable de dire, à forciori sur sa machine personelle, cet utilisateur ne pourra pas executer cette commande. Il faut déjà un bon niveau en informatique.
(Ps sur mes serveur un tant soit peu sécurisé, j'ai un PermitRootLogin no sur mon sshd_config.
J'aimerais savoir comme tu t'authentifie par su avec une clé.)
Tu n'a pas accès à su si tu es venu par login/mot de passe depuis le domaine. Tu n'es pas dans le bon groupe.
De toute façon pour avoir vraiment les droits root sur le domaine entier il faut :
- être sur le bon VLAN
- Se logguer au firewall avec un utilisateur wheel via clef. PFauth et PFSync se mettent en route.
- Récupérer le port à la con qui change tout le temps
- Se logguer au domaine avec la clef root sur le port à la con qui change en permanence
- Pendant mes heures de veille, répondre au téléphone pour m'expliquer lentement pourquoi il y a eu besoin de se loguer en root sur le domaine. Toute réponse non satisfaisante entrainne la fermeture de la session et l'invalidation de la clef.
Je ne sais pas comment prendre ton post. Déjà je suis très surpris d'apprendre que jail n'est pas géré par le système, j'imagine qu'il doit encore s'agir d'un coup des leprechaums... Dans mon esprit Jail était une fonctionnalité kernel d'isolation par virtualisation+containers . Un peu comme SE Linux en fait.
Mais même sur des authentifications très différentes de SE Linux, comme par exemple kerberosV ou pfauth, j'ai du mal à voir en quoi elles ne sont pas gérées par le système.
En ce qui concerne ce que je n'ai pas compris (et que donc je ne peux invalider) peux-tu s'il te plait me donner la signification des posts suivants.
Plus tu as de comptes , plus tu as de risques qu'un de ces comptes se fasse avoir. Si en plus tu dis à l'attaquant quel compte il faut qu'il cible pour avoir tel ou tel accès, tu crois vraiment que l'attaquant va s'en priver ?
Alors certes root c'est le graal, mais il est souvent protégé un minimum.
Les comptes subsidiaires peuvent avoir des mdp moins complexe et ainsi de suite.
(PBPG) un compte peut te permettre de changer les parametres reseau
(Briaeros)Tu as ça sur les postes privé non intégré à une entreprise ? (ie des postes perso quoi).
Parce que c'est bien ce dont tu parlais hein...
merci pbpg pour nous expliquer a quoi sert un compte avec des droits étendu et pourquoi on demande le mot de passe pour une modification de privilèges....
Les unixiens ont a jamais du voir ça.
On parlais de sudo & co. Dans ce système root c'est uid=0. Point barre. uid=0 a des droits. Point barre.
Parcequ'il y a deux façons de les interpreter :
- soit tu changes alégrement les points de vues quand ca t'arrange, passant de l'entreprise au réseau familial, de la protection par pur mot de passe à l'élévation des privilèges et du distinguo uid au distinguo privilèges un peu au moment ou ca t'arrange.
- Soit tu confonds des notions de sécurité par groupe avec des notions de sécurité par AC
Dans le doute j'avais pris la seconde option, moins insultante pour toi.
(et je te ferais remarquer que TU as traité tout le monde de nullard (sauf toi et pbpg)
J'ai simplement constaté de visu que tous les postes qui essayaient de mettre en exergue les différences entre le système d'évaluation des droits par AC et les sytèmes type sudo, se faisaient violamment moinsser. Et je n'ai pas traité les gens de nullards, j'ai simplement dit que la confusion qui semblait régner entre les anciens modes de sécurité et les nouveaux chez les lecteurs de LinuxFR me faisait peur. Je dis 'semblait' car j'espère sincèrement que ceux qui comprennent les enjeux des AC se sont détournés de ce thread parti en eau de boudin un vendredi.
Maintenant si mon invalidation te déplait, en voici quelques autres :
- 1) Le système qui permet de savoir quel utilisateur a le droit d'effectuer quelle commande n'est pas nécessairement accessible à l'ensemble des utilsateurs. On peut même penser qu'un administrateur va en limiter l'accès aux seuls gens qui en ont besoin. Comme pour tout autre système.
- 2) En entreprise, parcourir tout un arbre de droits, sur le LDAP domaine puis le recouper avec les droits et les restrictions locales d'une machine pour savoir qui peut ou ne peut pas lancer telle commande est loin d'être trivial. C'est même un problème NP complet je pense.
- 3) L'utilité d'un tel système en entreprise est double. Il permet de façon évidente de trouver quel autre utilisateur peut lancer la commande dont on a besoin. Mais aussi, et c'est peut être même plus interressant que la fonctionnalité évidente, il permet de sortir une liste des utilisateurs qui ont des droits qu'ils ne devraient pas avoir. Et donc de faire le ménage dans les droits de façon autrement plus simple que de passer sur tous les répertoires pour vérifier qu'il n'y a pas un accès qui n'a pas été retiré ou qui a été attribué par erreur. Vu la complexité que peut prendre les règles de sécurité dans un environnement d'entreprise, un tel outil est très précieux. Je confirme en plus qu'il n'y a aucun utilitaire unix à ma connaissance capable de donner la liste complète (domaine + local) des comptes capables de faire un rm sur tel fichier.
- 4) Au domicile, un tel système permet surtout à l'adminsitrateur local (généralement connu sous le nom de papa) de vérifier que les différents acteurs de son réseau ne peuvent pas, par exemple, enlever la protection parentale, continuer à surfer après 22h30, installer n'importe quoi. Il permet aussi aux enfants de savoir si ce qu'ils sont en train de faire (installer un jeu par exemple) peut être débloqué seulement par papa, ou bien par papa ET maman. Une fois de plus je n'ai jamais vu une telle fonctionnalité sur un Unix.
On parlais de sudo & co. Dans ce système root c'est uid=0. Point barre. uid=0 a des droits. Point barre.
Non TU parles de SUDO & co en disant que le truc de Microsoft est identique, PBPG parle d'un sytème de gestion de droit et de privilège qui n'a rien à voir avec sudo.
Même la base des bases qu'est runas est totalement différente de sudo.
Le système ne vas pas se dire "ah oui mais attend la il provient de tty2 donc je lui file les droits de backups, et la il provient de tty3 donc je lui file autre chose".
C'est con çà, moi mon système il fait "tiens il s'est logué par mot de passe, alors il se retrouve dans le jail de backup et de là il a pas les droits pour changer les sticky sur les fichiers et les dossiers", mais si il s'était logué par clef ca se serait passé différament.
Par contre, si tu étais si doué dans le mac, tu parlerais pas de "root" mais des != rôles ou équivalent. Parce que parler d'une partie fixe (le login) pour expliquer qu'il existe une partie variable (les rôles et leur droit associé) c'est complètement idiot.
Ben voyons, c'est toi qui voit des failles de sécurité dans l'affichage des utilisateurs capables de lancer une commande. J'imagine que c'est parceque tu te dis qu'une fois qu'on a le login on va finir par casser le mot de passe (en tout cas faciliter le cassage). Et je donne comme exemple pour invalider ton point de vue le fait qu'il est possible d'avoir un login/mot de passe root sans pour autant pouvoir faire quoi que ce soit sur la machine.
Et si ton ldap tombe, il fait comment le niveau 1 pour appeler savoir le gars qui est pas d'astreinte mais qui en réalité est d'astreinte ?
Si mes LDAP tombent tous en même temps (pas de bol quand même), on appelle directement le chef.
Tu as pas pensé a faire des procédures ? tes niveaux 1 naviguent entièrement au jugé et clique un peu n'importe où jusqu'à réussir a tomber sur la commande qu'il doivent lancer mais qu'ils ont pas les droits alors il ont un login (qui n'a peut être rien a voir avec le nom d'une personne rééel...))
Oui, mes niveaux 1 cliquouillent au hasard jusqu'à trouver la bonne ligne de commande. Ca leur prend un temps fou d'ailleurs. Oui les admins ont des logins complètement différents de leurs noms et prénoms, et en plus ils ne remplissent la fiche contact attachée à leur UID pour être sur qu'on ne les retrouve pas.
Oui on a pas de procédures, quand les niveau 1 arrivent on les assied devant leur ordi eteint et on les abandonne là jusqu'à ce que mort s'en suive.
On est très très très con dans ma boite.
Déjà apparament pas ceux qui lisent ce thread. Les explications de Pbpg sont très claires, mais un certain nombre de personne (dont toi) semblent confondre escalade de droit, changement de profil et passage en mode super-utilisateur.
Dans un monde ou les ACL et les containers sont en train de devenir la norme, je ne te cache pas que ca fait un peu peur.
Pour te donner une idée j'ai sur un de mes serveurs FreeBSD un utilisateur root qui n'a comme droit super user que celui de créer des backups avec préservation des ACL (et il ne peut même pas effacer ou modifier ses propres backups). Bien entendu le même utilisateur root qui se connecte différamment aura d'autres droits.
De même ces mêmes lecteurs de threads ne semblent pas voir l'intéret qu'il y a à connaitre l'utilisateur qui peut (par exemple) relancer un daemon ou un serveur. Or je peux te garantir que dans un domaine LDAP avec des groupes systèmes, des groupes domaines, des groupes locaux, des containers de sécurité et des règles de sécurité locale ca peut devenir loin d'être évident. Pourtant c'est utile pour le niveau 1 de savoir quel admin on apelle à 3h du matin pour relancer le serveur de mail.
Et en passant, dans le cas de Windows c'est pas forcement un changement d'utilisateurs, tu peux aussi passer de l'utilisateur X avec droits restreints a X avec droits complets, concept que Unix en general n'a pas.
Même si je suis plutôt d'accord avec toi sur ce coup là, et que je suis contre sudo (sudo MUST DIE !) Il existe plusieurs manières de faire qu'un utilisateur passe de droit restreints à des droits plus étendus sans changer de compte.
Les méthodes les plus connues sous Linux sont les outils SE Linux. Sous FreeBSD, et d'autres Unixes on peut créer des comportements equivalents avec MAC (Mandatory Access Control)
</rapport values="toto='1',tutu='{if tata<>0 then 1 else select monchamps from matable where truc end}', .... , rendu='echo \"\<html\>\<body\>{$tutu}\</br\>{$tata}....\</html\>\"' '"
De façon général toutes les branches de l'arbre s'appellaient rapport. On a vu trainer une branche debug une fois (mais après un appel au support, les fonctions de debug ne sont pas accessibles sur le logiciel client).
Pour un logiciel de reporting...
Et je compte pas les innombrables cas de transformation XML qui transforment
[section]
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
En
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
En passant, alsa, gstreamer, PA, libaudio etc ne font pas la même chose !
Non, libaudio est supposé aider à tirer parti d'Alsa, il y arrive modérément.
Pulse audio permet de faire pas mal de choses, mais dans 90% des cas il est utilisé comme mixeur soft, ce qui est un boulot qui devrait être assuré par Alsa et facilité par libaudio. Quand à GStreamer... On va dire que c'est une interface générique, mais avec pas mal d'exception, qui permet de décoder, de répartir et d'égaliser du son mais dont le but principal ne semble pas du tout d'être que le son qui sorte des enceintes soit le plus propre possible (Gapless, respect de la dynamique, priorité d'une appli sur l'autre etc.).
Pour faire trois rien, c'est possible. Pour le support hotplug, non, pour le bluetooth, non, etc.
OSS a des défauts, mais en ce qui concerne ma petite personne sur mon matos il a les avantages suivants par rapport à Alsa :
- Jouer la musique en Gapless sans surprises notables
- Le mixage soft fonctionne et fonctionne bien
- Marche assez bien avec Jack/ardour sans rajouter des latences démoniaques alors que je n'ai pas un kernel realtime
- Fonctionne aussi sous Freebsd
- Marche très très bien avec les clients MPD et XMMS
Après çà Alsa a des avantages technologiques indenniables sur le papier, notemment au niveau de la propreté vis à vis du kernel, mais je vais attendre qu'il y en ai quelques uns qui se réalisent dans la vraie vie avant de changer de système...
Si j'ai bien compris, ça faisait longtemps qu'OSS était émulé au dessus d'ALSA, mais l'émulation était faite dans le noyau. Or c'est quelque chose de compliqué, lourd et bogué. Et puis, personne ne voulait plus le maintenir. J'ai bon ?
En fait dès que OSS est passé en source fermées, il est simultanément devenu très problématique au niveau technique.
De façon générale OSS considère qu'il ne devrait y avoir qu'une seule API qui gouverne le Hardware en mode kernel et qui soit accessible via les fonctions POSIX d'accès fichier de base, avec juste une modification pour savoir si il y a du changement de fréquence ou pas. Ensuite charge à l'appli et au noyal de se démerder pour que le buffer son ne se remplisse pas et qu'il se vide correctement et dans les temps.
Pour Alsa c'est assez différent, en fait on peut aussi accéder aux son Alsa via les méthodes POSIX de base, ou via 250 000 autres interfaces ou méthodes dont au moins 6 sont doccumentées. Alsa est conçu pour ne pas faire de lock exclusif en mode kernel du hardware (du moins en théorie, parcequ'en pratique ca plante si on essaye de partager) et de plus les API d'ouverture, de buffer ou de mixage ne sont pas nécessairement dans le noyeau mais peuvent être reportées en user space (ce qui plante aussi dans 90% des cas - et de toute façon la plupart des méthodespour faire ce genre de choses sont non documentées)
De fait tout le monde utilise la bibliothèque libaudio, et au sein des 800 000 fonctions tout le monde utilise les 4 ou 5 mêmes... Bref à aujourd'hui Alsa a à peut près tous les défauts d'OSS tout en étant vraiment moins bien documenté.
Généralement dès que quelqu'un arrive à faire marcher un truc dans Alsa de façon à peu près reproductible, ca devient de facto le standard. C'est pour çà qu'on a aujourd'hui l'appli sur gstreamer sur pulse audio sur Alsa... Avec les conséquences que celà peut avoir sur la lecture gapless par exemple. Si personne n'y arrive, l'API Alsa est modifiée en profondeur. Par exemple pour le mixage on a eu tout et le reste : Avant pulse audio (qui commence à marcher péniblement quand on le chatouille pas trop fort) on a eu le droit a un buffer software, un facteur d'amplification dans la connexion sonore, des devices virtuels à créer à la main, des devices virtuels qui se créaient tout seuls au besoin etc.
Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.
Oui j'utilises PF avec FWBuilder[1] qui est une interface très bien faites pour créer les règles (QT).
A moins que ca ait vraiment changé, les règles créées par FWBuilder pour PF sont sous optimales. La plupart sont en quick et on ne peut pas tirer parti facilement des différentes protections anti-hammering/sniffing qu'offre PF, ni des tables dynamiques, ni des tags.
J'utilisait FWBuilder au début, et je me suis très vite retrouvé avec un nombre de règles démentiel (un peu plus de mille). Maintenant j'ai la même chose à la mano avec une soixantaine de règles. Les gains en performances/lisibilité/maintenabilité sont très appréciables.
Excellent choix. Mais Avec PF + Carp + PFSync + PFauth c'est encore meilleur. Bon il faut se farcir la conf à la mimine, mais avec les macros ca se passe très très bien.
Avec sudo tu peux spécifier exactement la commande que l'utilisateur à le droit, tu peux donc autoriser par application les droits ...
Attention Marcel, là on va te renvoyer les ACL windows ou Active Directory à la gueule et tu vas pas comprendre ta douleur....
Sous Windows On peut donner les droits sur n'importe quel élément à n'importe quel utilisateur sans jamais que l'utilisateur en question ne subissent la moindre élévation de privilège.
Sous Linux aussi on a des ACL et il faudrait s'en servir, sous FreeBSD on des des ACL étendus au hardware en plus des ACL fichier et c'est le bonheur. De façon générale mon point de vue est "sudo MUST DIE"..
Comme je suis le bien involontaire auteur de ce troll, je permettrais juste un commentaire :
Je ne connais pas à fond la théorie des cordes (loin de là) mais il me semble que les paramètres sont pour la plupart inter compensés (i.e : il est difficile d'invalider complètement les valeurs d'un paramètre, car on peut corriger un modèle contredit par l'expérience en faisant varier les autres)
De fait on ne peut invalider complètement des pans entiers de la théorie, juste des tuples de plages de paramètres.
En invalidant une théorie par seconde il faut quand même plus de 3*10⁴⁹² années pour évacuer la théorie des cordes.
C'est combien déjà la durée de vie de l'univers ?
[^] # Re: la verite est... quelque part
Posté par Jerome Herman . En réponse au journal Bruce Perens, l'auteur de Busybox, s'exprime sur l'affaire. Évalué à 2.
Au risque de me faire moinsser encore une fois, je tente une autre explication plus terre à terre.
J'écris un policier fantastique qui ne marche pas. Mon héro JIM retourne au placard.
Quelqu'un que je ne connais pas décide de faire la suite des aventures de JIM en lui adjoignant une coequipière VLADA qui est en fait une vampire.
Il a besoin de ma permission pour écrire cette suite, et je peux y opposer mon droit moral même si j'ai vendu les droits patrimoniaux sur les aventures de JIM.
La série des aventures de JIM et VLADA marche du feu de dieu et l'auteur décide d'écrire un prologue dans lequel il raconte comment VLADA est devenu un vampire.
Bien sur l'histoire se passe au moyen age et n'a rien d'une enquète policière. Son histoire n'a aucun rapport avec rien de ce que j'ai écrit.
Accrochez-vous bien : parcequ'il écrit les aventures de VLADA après que les aventures de JIM et VLADA aient été un succès, il a besoin de ma permission pour écrire les aventures de VLADA. Si il me reste des droits patrimoniaux sur JIM je me peux même prétendre à des droits d'auteurs. Dans tous les cas je peux opposer mes droits moraux à son histoire.
Pourquoi ? Parceque les lecteurs connaissent déjà VLADA, parceque son histoire va profiter de la renommée acquise avec un perso que j'ai créé, parceque dans le cas d'histoire écrites à plusieurs mains (scénarios télé par exemple) c'est la seule solution pour qu'aucun des artistes ne soit lésé etc.
De mon coté je peux écrire autant d'aventure de JIM sans VLADA que je veux. Et ce sans rendre de compte à personne.
Alors maintenant je ne sais pas comment ca marche dans le cas d'un logiciel, et à forciori d'un logiciel en GPL. Mais de façon générale le droit européen en ce qui concerne le logiciel est très proche du droit d'auteur classique.
[^] # Re: Pourquoi nvidia ?
Posté par Jerome Herman . En réponse au journal Acheter un ordinateur portable en 2009.... Évalué à 1.
Sur les serveurs et sur certaines cartes mères il y a parfois des versions modifiées qui déconnent avec le driver ATI il faut alors forcer le driver Mach64.
Mais bon si c'est une puce montée sur carte mère c'est un poil perdu d'avance.
[^] # Re: la verite est... quelque part
Posté par Jerome Herman . En réponse au journal Bruce Perens, l'auteur de Busybox, s'exprime sur l'affaire. Évalué à 1.
Oui à part que comme initiateur il peut appliquer son droit moral pour bloquer tous les autres, et qu'aucun des autres ne peut le bloquer à part sur les points qu'ils ont eux mêmes créés. Je considère que c'est un poil plus fort...
Dans le pire des cas, tu changes le nom et la coupe de cheveux du personnage, et l'autre auteur n'aura plus rien dire, pour peu qu'il ne participe pas à la conception des nouvelles œuvres.
Tu peux changer le nom, le lieu, la coupe de cheveux, l'époque et le sexe du héro et t'en prendre plein la gueule quand même. Voir les dizaines de plagiats d'Harry Potter qui ont été renvoyés dans l'oubli.
Il faut pas abuser, je peux très bien parler du mickey de walt disney autant qu'il me plaît sans avoir à verser un centime à qui que ce soit.
Pas vraiment non. Dans le cercle privée oui, pour une critique ou une analyse oui, mais si tu créés une oeuvre (ce qui est un peu le cas qui nous interresse là) dans laquelle Mickey Mouse vient faire de la figuration, même fugitivement, même en arrière plan, même si c'est un truc qui pourrait être pris pour Mickey Mouse de loin dans le brouillard etc. Il est très probable que Walt Disney corp vienne te taper sur l'épaule pour demander au mieux un cheque, au pire que tu retires complètement toute référence à la souris de ton truc sous pretexte que ca nuit à l'image.
[^] # Re: la verite est... quelque part
Posté par Jerome Herman . En réponse au journal Bruce Perens, l'auteur de Busybox, s'exprime sur l'affaire. Évalué à 1.
C'est à dire pas grand chose. En tant qu'auteur initial je peux exercer mon droit moral pour bloquer ses histoires, et me mettre à en écrire d'autres sans qu'il ne puisse rien dire du moment que je ne reprend aucun des éléments qu'il a introduit lui même.
il est également interdit de ne pas respecter la paternité de l'auteur subséquent.
Si et seulement si je reprend des éléments signicatifs qui ont été créé par le nouvel auteur. Sinon je fais ce que je veux.
[^] # Re: Pourquoi nvidia ?
Posté par Jerome Herman . En réponse au journal Acheter un ordinateur portable en 2009.... Évalué à 6.
C'est à dire que les quelques chipsets graphiques qui sont pleinement supportés par Linux, c'est à dire les matrox G200 et G400, les S3 Virge, les Ati Rage 128 et rage Pro sont un poil anciens.
Tous les autres chipsets, à forciori dans leur version "mobility" deconnent à pleins tubes sous Linux que ce soit avec les pilotes libres ou les pilotes proprios, en 2D ou en 3D, en Xorg ou en framebuffer console.
Attention je ne dis pas qu'il n'y a pas des PC ou des mobiles sous Linux qui ne fonctionnent pas très bien avec des chipsets graphiques modernes. Je dis juste qu'à l'achat d'un portable, a moins d'avoir un pote qui a installé le même portable de la même série avec le même bios, il est impossible de savoir à quel point l'affichage va decconner.
Généralement sur portable on fini avec un driver vesa, ce qui est super pour la 2D/3D/Lecture de film etc.
Curieusement, NVidia, tout propriétaire qu'il soit, est le constructeur qui fait le plus d'effort pour rester à la page avec les évolutions de Linux (le kernel, j'ai pas oublié le GNU/)
Intel et AMD font pas mal d'annonces et de presse release, mais bon ne serait-ce que pour activer les transparences Hard en 2D il faut y aller pendant un moment...
[^] # Re: la verite est... quelque part
Posté par Jerome Herman . En réponse au journal Bruce Perens, l'auteur de Busybox, s'exprime sur l'affaire. Évalué à 0.
Je ne sais pas comment ca se passe aux US, ni sur les logiciels. Mais en ce qui concerne le droit d'auteur classique, la paternité EST l'apanage de l'auteur initial.
Par exemple si je créé un personnage que j'apelle bidule, et que ce personnage fait un bide total dans une série/un roman/un film.
Maintenant supposons qu'un autre auteur décide de reprendre mon personnage de bidule pour en faire lui une série/un roman/un film à succès. Le mec a beaucoup plus d'idées que moi, il écrit mieux et il a indiscutablement plus de talent. Cependant le créateur du personnage c'est moi. J'ai droit de regard sur tout ce que fait le nouvel auteur. Je peux exercer mes droits moraux pour empécher que le personnage bidule ne fasse ceci ou celà. Je touche de l'argent à chaque fois que le personnage bidule est mentionné etc.
Vu les précautions prises par Marvel sur les super-héros, et les textes longs comme le bras sur les droits des scénaristes des séries américaines, je me dis que ca doit pas être très différents aux US.
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Jerome Herman . En réponse au journal Certains OGM prouvés nocifs. Évalué à 8.
Pas d'accord.
J'ai entre 25 et 40 ans, je suis en bonne santé, je suis dans une tranche ou la probabilité de sequelles suite à une grippe est grosso-modo égale voire inférieure à la probabilité combiné d'une réaction au vaccin, d'une ineffectivité du vaccin, d'une réaction allergique.
Vu le taux de population contaminée ma probabilité d'avoir déjà été en contact avec le virus, voire de rentrer en contact avec le virus pendant la developpement de la réponse immunitaire est loin d'être négligeable (Je prend le métro, et comme en ce moment il y a grève sur le RER A c'est convivial les trajets).
Pour toute ces raisons, je reste loin du vaccin. Les choses aurait été différente si, comme dans le reste du monde, la vaccination avait pu avoir lieu dans les temps. mais se faire vacciner le 15 décembre pour un virus qui a déjà touché 5 millions de compatriotes ca me parait douteux.
Maintenant c'est mon opinion, et je n'ai rien d'un expert en immunologie.
[^] # Re: Hum
Posté par Jerome Herman . En réponse au journal La physique et les phénomènes. Évalué à 6.
Tout petit joueur
http://fr.wikipedia.org/wiki/Tsar_Bomba
[^] # Re: Ratai
Posté par Jerome Herman . En réponse au journal Sortie de LyX 1.6.5. Évalué à 3.
Ni l'un ni l'autre, c'est (X²-1)/X
En effet soit X
L'inverse c'est 1/X
Donc la différence de l'inverse c'est X-1/X. CQFD
[^] # Re: Disfonctionnement.
Posté par Jerome Herman . En réponse au journal Chez mandarin, un forfait illimité à 90 euros peut produire une facture à 45000 euros. Évalué à 8.
C'est pas du temps réel d'accord. mais on a pas mal de cartes 3G dans ma boite, et quand un commercial abuse un peu de l'internet à l'étranger (Israel, Quatar, Canada, US, Brésil etc.) Je suis prévenu dans les 48h avec une option stop ou encore.
J'ai du mal à croire que la taxation, même si elle est passée par la Belgique, ait pu monter à 45 000€ sans que personne ne s'en apperçoive.
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 2.
C'est quoi la politique de sécurité effectuée par le système ? La séparation kernel mode/user mode ? Parceque UID/GID c'est les routines file system (au sens large) qui gèrent, SE Linux c'est les routines SE Linux, etc. J'aimerais vraiment comprendre le distinguo que tu fais entre des routines kernel de sécurité avec limitations d'une part et d'autres routines kernel de sécurité avec limitation d'autre part.
SE Linux a rien a voir avec un jail ou un chroot.
C'est un système de virtualisation + cotainers. Il est utilisé différamment certes mais fondamentalement c'est exactement le même principe sous-jacent.
Il n'y a pas d'authentification "se linux"
Alors comment donne-t-il les droits ? Si il n'y pa pas de système qui permette de savoir qui a les droits (ie authentification) que fait SE Linux pour les attribuer ? Il tire au sort ?
N.B il existe plusieurs méthodes d'authentification (je suis (bio-métrie), je connais (mot de passe ou clef), je sais faire (door knocking, sign pad), j'ai fait(élévation de privilèges, réattribution de droit, login tortueux))
De plus, c'est pas moi qui confond en utilisant la partie fixe pour parler de la partie variable hein...
Enfin, tu utilise AC pour account control, (Mandatory?) access control , ... ?
Tu dis que c'est gravissime de connaitre les logins qui ont accès à tel ou tel outil, je réponds que ce n'est plus le cas aujourd'hui. Parceque même si le login est une condition nécessaire, ce n'est plus une condition suffisante (justement à cause de la partie variable comme tu l'appelles). Ceci étant, pour ta gouverne sache que dans environnement de domaine la partie fixe est l'UID pas le login. Sur mes serveur root peut être 0, 514 ou 10000 suivant les cas. Avec le même login et le même mot de passe (bon pour 0 il faut la clef). C'est kerberos/LDAP qui attribue le UID suivant l'authentification...
Quand à AC, c'est l'abrevation de access control. Ca englobe tout ce qui est MAC, ACL, jail, SE Linux etc. Bref tout ce qui est attribution/retraits de droits en plus du couple UID/GID
Donc tes procédures ne sont pas à jour et tu as besoin que le système te tienne par la main pour te dire qui a le droit ou pas.
a) En entreprise c'est pas forcément moi qui ait monté le système/domaine
b) En entreprise je suis pas forcément seul et avec la maitrise absolue sur le système/domaine
c) En entreprise il y a des gens qui vont, qui viennent, qui prennent des vacances qui changent de postes, qui prennent des assitants etc.
d) En entreprise il y a des softs fermés dont le vendeur n'assure pas la maintenance si les utilisateurs n'ont pas tel et tel droits.
Après monter un système tel que M. Truc qui a beoin de faire les taches 1, 2 et 4 mais pas la tache 3 et qui quand il part en vacances a besoin que madame chose fasse les taches 1 et 2 et que monsieur bidule prenne en charge la tache 4 nécessite une gestion complète. Si tu es capable de gérer tout çà de tête, félicitation pour toi (à moins que tu ne bosses dans une petite entreprise, ou une boite ou la sécurité n'est pas primordiale). Personellement je bosse pour de très grands groupes étalés sur plusieurs pays, dont des banques. Le nombre de scripts mis en place qui ne servent qu'à déplacer les fichier du dossier a vers le dossier b en changeant les droits au passage est assez impressionant. Mais si on ne le fait pas on se retrouve avec des effets de bords désagréables de type "machin a besoin de faire la tache 1 et la tache 4 mais il se retrouve également avec les droits pour lire les résultats de la tache 3".
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
Je reprend :
Tu as un domaine, dans ce domaine tu as une forêt d'annuaire LDAP avec des relations de confiance les uns avec les autres ou pas. Ensuite tu as des politiques de sécurité certaines dans le domaine, certaines dans l'annuaire LDAP concernée, certaines dans l'annuaire LDAP de l'utilisateur et enfin certaines sur la machine de l'utilisateur et sur le serveur de l'application. Trouver l'ensemble des utilisateurs capables de lancer telle commande avec tels arguments sur l'ensemble du domaine doit être un problème NP complet je pense.
Bien entendu dans la vraie vie on s'arrange pour que ce soit des groupes locaux qui contiennent des groupes LDAP qui sont à leurs tour inscrit dans des politiques domaines. Ce qui rend la détermination de droits plus simple, mais la possibilité de créer des effets de bords reste élevée.
Dans une boite où j'interviens c'était à peu près ce qui ce passé. Conclusion, maintenant c'est "les sysadmins se déplacent quand vous avez besoin de lancer un truc".
Bonjour, les sysadmin sont à Paris et à Toronto. L'utilisateur est à Singapour. Ah, et il lance ce type d'opération 300 fois par jour. C'est la validation/renouvellement des clefs de confiance tierces, légalement il faut une validation humaine. Il lui faut les droits sur le LDAP. A vous.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
On peut tout faire en langage machine sur une machine Turing Complete. La question est peut on le faire bien, de façon fiable dans un temps raisonnable (ie avant que Mme Chose ait besoin d'autres droits). Pas facile. Ca se fait avec des réseaux de Petri coloré par exemple quand on veut être sur de couvrir tous les cas et tous les effets de bords. Le seul ennui est que quasiment personne n'est capable de formaliser un problème de droits à l'échelle d'une boite internationale avec un réseau de Petri. Donc on pense avoir fait les choses proprement, mais on a pas de preuves (au sens mathématique du terme).
Sur la plupart des machines que j'administre, je peux trouver ça sans trop de problème par contre).
Si tu as du mal a trouver ça, c'est peut être que ta politique de sécurité crains un peu, tu ne crois pas ?
Si tu utilise juste les droits UID/GID ca ne pose pas de problèmes en effet. Mais des fois ca ne suffit pas comme droits.
Quand à ma politique de sécurité ca fait trois année de suite que l'audit "surprise" se termine en 30 minutes avec l'auditeur qui est coupé du réseau et qui est obligé d'appeler pour qu'on le débloque de façon à pouvoir finir ses tests (donc au niveau surprise, plouf)
Et puis si on les a rajouté c'est qu'il y a une raison... et si on les a pas supprimé c'est aussi qu'il y a une raison.
Le problème n'est pas là. Un utilisateur X qui n'a plus besoin de l'application A, doit-il garder les droits sur le répertoire 1 utilisé par l'application A mais aussi par d'autres applications dans certains cas.
Répondre à cette question nécessite de savoir parfaitement ce que fait cet utilisateur et d'avoir une architecture complète et à jour de tous les SI pour savoir si l'utilisation 12 de l'application B ne nécessite pas aussi les droits sur répertoire 1.
De plus il est très fréquents que deux utilisateurs qui ont un répertorie en commun l'utilise pour autre chose que ce qui est prévu pour des raisons pratiques. Donc quand on ferme le répertoire 1 à un des deux utilisateurs ca gueule qu'une tache qui n'a rien à voir ne marche plus. Des fois quand c'est un grand ponte qui gueule (Forex ou Trésorerie par exemple) tu recois l'ordre de rendre le répertoire à l'utilisateur qui ne devrait plus en avoir besoin.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Je ne connais pas grand monde qui soit capable de dire, à forciori sur sa machine personelle, cet utilisateur ne pourra pas executer cette commande. Il faut déjà un bon niveau en informatique.
(Ps sur mes serveur un tant soit peu sécurisé, j'ai un PermitRootLogin no sur mon sshd_config.
J'aimerais savoir comme tu t'authentifie par su avec une clé.)
Tu n'a pas accès à su si tu es venu par login/mot de passe depuis le domaine. Tu n'es pas dans le bon groupe.
De toute façon pour avoir vraiment les droits root sur le domaine entier il faut :
- être sur le bon VLAN
- Se logguer au firewall avec un utilisateur wheel via clef. PFauth et PFSync se mettent en route.
- Récupérer le port à la con qui change tout le temps
- Se logguer au domaine avec la clef root sur le port à la con qui change en permanence
- Pendant mes heures de veille, répondre au téléphone pour m'expliquer lentement pourquoi il y a eu besoin de se loguer en root sur le domaine. Toute réponse non satisfaisante entrainne la fermeture de la session et l'invalidation de la clef.
[^] # Re: La solution la plus propre
Posté par Jerome Herman . En réponse au journal L'informatique ou comment devenir fou. Évalué à 9.
Bon ben tu as ta réponse, il y a un bug dans le chipset/driver de ta carte wifi, à chaque fois qu'on la probe, elle change d'état.
Tu peux redevenir sain d'esprit maintenant.
[^] # Re: La solution la plus propre
Posté par Jerome Herman . En réponse au journal L'informatique ou comment devenir fou. Évalué à 2.
Pour voir...
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 1.
Mais même sur des authentifications très différentes de SE Linux, comme par exemple kerberosV ou pfauth, j'ai du mal à voir en quoi elles ne sont pas gérées par le système.
En ce qui concerne ce que je n'ai pas compris (et que donc je ne peux invalider) peux-tu s'il te plait me donner la signification des posts suivants.
Plus tu as de comptes , plus tu as de risques qu'un de ces comptes se fasse avoir. Si en plus tu dis à l'attaquant quel compte il faut qu'il cible pour avoir tel ou tel accès, tu crois vraiment que l'attaquant va s'en priver ?
Alors certes root c'est le graal, mais il est souvent protégé un minimum.
Les comptes subsidiaires peuvent avoir des mdp moins complexe et ainsi de suite.
(PBPG) un compte peut te permettre de changer les parametres reseau
(Briaeros)Tu as ça sur les postes privé non intégré à une entreprise ? (ie des postes perso quoi).
Parce que c'est bien ce dont tu parlais hein...
merci pbpg pour nous expliquer a quoi sert un compte avec des droits étendu et pourquoi on demande le mot de passe pour une modification de privilèges....
Les unixiens ont a jamais du voir ça.
On parlais de sudo & co. Dans ce système root c'est uid=0. Point barre. uid=0 a des droits. Point barre.
Parcequ'il y a deux façons de les interpreter :
- soit tu changes alégrement les points de vues quand ca t'arrange, passant de l'entreprise au réseau familial, de la protection par pur mot de passe à l'élévation des privilèges et du distinguo uid au distinguo privilèges un peu au moment ou ca t'arrange.
- Soit tu confonds des notions de sécurité par groupe avec des notions de sécurité par AC
Dans le doute j'avais pris la seconde option, moins insultante pour toi.
(et je te ferais remarquer que TU as traité tout le monde de nullard (sauf toi et pbpg)
J'ai simplement constaté de visu que tous les postes qui essayaient de mettre en exergue les différences entre le système d'évaluation des droits par AC et les sytèmes type sudo, se faisaient violamment moinsser. Et je n'ai pas traité les gens de nullards, j'ai simplement dit que la confusion qui semblait régner entre les anciens modes de sécurité et les nouveaux chez les lecteurs de LinuxFR me faisait peur. Je dis 'semblait' car j'espère sincèrement que ceux qui comprennent les enjeux des AC se sont détournés de ce thread parti en eau de boudin un vendredi.
Maintenant si mon invalidation te déplait, en voici quelques autres :
- 1) Le système qui permet de savoir quel utilisateur a le droit d'effectuer quelle commande n'est pas nécessairement accessible à l'ensemble des utilsateurs. On peut même penser qu'un administrateur va en limiter l'accès aux seuls gens qui en ont besoin. Comme pour tout autre système.
- 2) En entreprise, parcourir tout un arbre de droits, sur le LDAP domaine puis le recouper avec les droits et les restrictions locales d'une machine pour savoir qui peut ou ne peut pas lancer telle commande est loin d'être trivial. C'est même un problème NP complet je pense.
- 3) L'utilité d'un tel système en entreprise est double. Il permet de façon évidente de trouver quel autre utilisateur peut lancer la commande dont on a besoin. Mais aussi, et c'est peut être même plus interressant que la fonctionnalité évidente, il permet de sortir une liste des utilisateurs qui ont des droits qu'ils ne devraient pas avoir. Et donc de faire le ménage dans les droits de façon autrement plus simple que de passer sur tous les répertoires pour vérifier qu'il n'y a pas un accès qui n'a pas été retiré ou qui a été attribué par erreur. Vu la complexité que peut prendre les règles de sécurité dans un environnement d'entreprise, un tel outil est très précieux. Je confirme en plus qu'il n'y a aucun utilitaire unix à ma connaissance capable de donner la liste complète (domaine + local) des comptes capables de faire un rm sur tel fichier.
- 4) Au domicile, un tel système permet surtout à l'adminsitrateur local (généralement connu sous le nom de papa) de vérifier que les différents acteurs de son réseau ne peuvent pas, par exemple, enlever la protection parentale, continuer à surfer après 22h30, installer n'importe quoi. Il permet aussi aux enfants de savoir si ce qu'ils sont en train de faire (installer un jeu par exemple) peut être débloqué seulement par papa, ou bien par papa ET maman. Une fois de plus je n'ai jamais vu une telle fonctionnalité sur un Unix.
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 3.
Non TU parles de SUDO & co en disant que le truc de Microsoft est identique, PBPG parle d'un sytème de gestion de droit et de privilège qui n'a rien à voir avec sudo.
Même la base des bases qu'est runas est totalement différente de sudo.
Le système ne vas pas se dire "ah oui mais attend la il provient de tty2 donc je lui file les droits de backups, et la il provient de tty3 donc je lui file autre chose".
C'est con çà, moi mon système il fait "tiens il s'est logué par mot de passe, alors il se retrouve dans le jail de backup et de là il a pas les droits pour changer les sticky sur les fichiers et les dossiers", mais si il s'était logué par clef ca se serait passé différament.
Par contre, si tu étais si doué dans le mac, tu parlerais pas de "root" mais des != rôles ou équivalent. Parce que parler d'une partie fixe (le login) pour expliquer qu'il existe une partie variable (les rôles et leur droit associé) c'est complètement idiot.
Ben voyons, c'est toi qui voit des failles de sécurité dans l'affichage des utilisateurs capables de lancer une commande. J'imagine que c'est parceque tu te dis qu'une fois qu'on a le login on va finir par casser le mot de passe (en tout cas faciliter le cassage). Et je donne comme exemple pour invalider ton point de vue le fait qu'il est possible d'avoir un login/mot de passe root sans pour autant pouvoir faire quoi que ce soit sur la machine.
Et si ton ldap tombe, il fait comment le niveau 1 pour appeler savoir le gars qui est pas d'astreinte mais qui en réalité est d'astreinte ?
Si mes LDAP tombent tous en même temps (pas de bol quand même), on appelle directement le chef.
Tu as pas pensé a faire des procédures ? tes niveaux 1 naviguent entièrement au jugé et clique un peu n'importe où jusqu'à réussir a tomber sur la commande qu'il doivent lancer mais qu'ils ont pas les droits alors il ont un login (qui n'a peut être rien a voir avec le nom d'une personne rééel...))
Oui, mes niveaux 1 cliquouillent au hasard jusqu'à trouver la bonne ligne de commande. Ca leur prend un temps fou d'ailleurs. Oui les admins ont des logins complètement différents de leurs noms et prénoms, et en plus ils ne remplissent la fiche contact attachée à leur UID pour être sur qu'on ne les retrouve pas.
Oui on a pas de procédures, quand les niveau 1 arrivent on les assied devant leur ordi eteint et on les abandonne là jusqu'à ce que mort s'en suive.
On est très très très con dans ma boite.
Allez hop, PLONK !
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 2.
Déjà apparament pas ceux qui lisent ce thread. Les explications de Pbpg sont très claires, mais un certain nombre de personne (dont toi) semblent confondre escalade de droit, changement de profil et passage en mode super-utilisateur.
Dans un monde ou les ACL et les containers sont en train de devenir la norme, je ne te cache pas que ca fait un peu peur.
Pour te donner une idée j'ai sur un de mes serveurs FreeBSD un utilisateur root qui n'a comme droit super user que celui de créer des backups avec préservation des ACL (et il ne peut même pas effacer ou modifier ses propres backups). Bien entendu le même utilisateur root qui se connecte différamment aura d'autres droits.
De même ces mêmes lecteurs de threads ne semblent pas voir l'intéret qu'il y a à connaitre l'utilisateur qui peut (par exemple) relancer un daemon ou un serveur. Or je peux te garantir que dans un domaine LDAP avec des groupes systèmes, des groupes domaines, des groupes locaux, des containers de sécurité et des règles de sécurité locale ca peut devenir loin d'être évident. Pourtant c'est utile pour le niveau 1 de savoir quel admin on apelle à 3h du matin pour relancer le serveur de mail.
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 3.
Même si je suis plutôt d'accord avec toi sur ce coup là, et que je suis contre sudo (sudo MUST DIE !) Il existe plusieurs manières de faire qu'un utilisateur passe de droit restreints à des droits plus étendus sans changer de compte.
Les méthodes les plus connues sous Linux sont les outils SE Linux. Sous FreeBSD, et d'autres Unixes on peut créer des comportements equivalents avec MAC (Mandatory Access Control)
# Reccord à battre
Posté par Jerome Herman . En réponse au journal Le cauchemard de l'ETL. Évalué à 2.
</rapport values="toto='1',tutu='{if tata<>0 then 1 else select monchamps from matable where truc end}', .... , rendu='echo \"\<html\>\<body\>{$tutu}\</br\>{$tata}....\</html\>\"' '"
De façon général toutes les branches de l'arbre s'appellaient rapport. On a vu trainer une branche debug une fois (mais après un appel au support, les fonctions de debug ne sont pas accessibles sur le logiciel client).
Pour un logiciel de reporting...
Et je compte pas les innombrables cas de transformation XML qui transforment
[section]
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
En
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
[^] # Re: Révélateur.
Posté par Jerome Herman . En réponse au journal Et vous, que feriez vous avec 245 772€ ?. Évalué à 2.
Uniquement parce que le papier se délite ce qui le rend impropre aux traitements que l'on applique aux chèques.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Jerome Herman . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 2.
Non, libaudio est supposé aider à tirer parti d'Alsa, il y arrive modérément.
Pulse audio permet de faire pas mal de choses, mais dans 90% des cas il est utilisé comme mixeur soft, ce qui est un boulot qui devrait être assuré par Alsa et facilité par libaudio. Quand à GStreamer... On va dire que c'est une interface générique, mais avec pas mal d'exception, qui permet de décoder, de répartir et d'égaliser du son mais dont le but principal ne semble pas du tout d'être que le son qui sorte des enceintes soit le plus propre possible (Gapless, respect de la dynamique, priorité d'une appli sur l'autre etc.).
Pour faire trois rien, c'est possible. Pour le support hotplug, non, pour le bluetooth, non, etc.
OSS a des défauts, mais en ce qui concerne ma petite personne sur mon matos il a les avantages suivants par rapport à Alsa :
- Jouer la musique en Gapless sans surprises notables
- Le mixage soft fonctionne et fonctionne bien
- Marche assez bien avec Jack/ardour sans rajouter des latences démoniaques alors que je n'ai pas un kernel realtime
- Fonctionne aussi sous Freebsd
- Marche très très bien avec les clients MPD et XMMS
Après çà Alsa a des avantages technologiques indenniables sur le papier, notemment au niveau de la propreté vis à vis du kernel, mais je vais attendre qu'il y en ai quelques uns qui se réalisent dans la vraie vie avant de changer de système...
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Jerome Herman . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 10.
En fait dès que OSS est passé en source fermées, il est simultanément devenu très problématique au niveau technique.
De façon générale OSS considère qu'il ne devrait y avoir qu'une seule API qui gouverne le Hardware en mode kernel et qui soit accessible via les fonctions POSIX d'accès fichier de base, avec juste une modification pour savoir si il y a du changement de fréquence ou pas. Ensuite charge à l'appli et au noyal de se démerder pour que le buffer son ne se remplisse pas et qu'il se vide correctement et dans les temps.
Pour Alsa c'est assez différent, en fait on peut aussi accéder aux son Alsa via les méthodes POSIX de base, ou via 250 000 autres interfaces ou méthodes dont au moins 6 sont doccumentées. Alsa est conçu pour ne pas faire de lock exclusif en mode kernel du hardware (du moins en théorie, parcequ'en pratique ca plante si on essaye de partager) et de plus les API d'ouverture, de buffer ou de mixage ne sont pas nécessairement dans le noyeau mais peuvent être reportées en user space (ce qui plante aussi dans 90% des cas - et de toute façon la plupart des méthodespour faire ce genre de choses sont non documentées)
De fait tout le monde utilise la bibliothèque libaudio, et au sein des 800 000 fonctions tout le monde utilise les 4 ou 5 mêmes... Bref à aujourd'hui Alsa a à peut près tous les défauts d'OSS tout en étant vraiment moins bien documenté.
Généralement dès que quelqu'un arrive à faire marcher un truc dans Alsa de façon à peu près reproductible, ca devient de facto le standard. C'est pour çà qu'on a aujourd'hui l'appli sur gstreamer sur pulse audio sur Alsa... Avec les conséquences que celà peut avoir sur la lecture gapless par exemple. Si personne n'y arrive, l'API Alsa est modifiée en profondeur. Par exemple pour le mixage on a eu tout et le reste : Avant pulse audio (qui commence à marcher péniblement quand on le chatouille pas trop fort) on a eu le droit a un buffer software, un facteur d'amplification dans la connexion sonore, des devices virtuels à créer à la main, des devices virtuels qui se créaient tout seuls au besoin etc.
Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.
[^] # Re: De plus en plus ...
Posté par Jerome Herman . En réponse au sondage J'utilise (Open|Free|net)BSD. Évalué à 5.
A moins que ca ait vraiment changé, les règles créées par FWBuilder pour PF sont sous optimales. La plupart sont en quick et on ne peut pas tirer parti facilement des différentes protections anti-hammering/sniffing qu'offre PF, ni des tables dynamiques, ni des tags.
J'utilisait FWBuilder au début, et je me suis très vite retrouvé avec un nombre de règles démentiel (un peu plus de mille). Maintenant j'ai la même chose à la mano avec une soixantaine de règles. Les gains en performances/lisibilité/maintenabilité sont très appréciables.
[^] # Re: De plus en plus ...
Posté par Jerome Herman . En réponse au sondage J'utilise (Open|Free|net)BSD. Évalué à 3.
[^] # Re: Mon dieu quelle horreur
Posté par Jerome Herman . En réponse au journal Projet Églantine et les ouinedoziens - Épisode 2. Évalué à 5.
Attention Marcel, là on va te renvoyer les ACL windows ou Active Directory à la gueule et tu vas pas comprendre ta douleur....
Sous Windows On peut donner les droits sur n'importe quel élément à n'importe quel utilisateur sans jamais que l'utilisateur en question ne subissent la moindre élévation de privilège.
Sous Linux aussi on a des ACL et il faudrait s'en servir, sous FreeBSD on des des ACL étendus au hardware en plus des ACL fichier et c'est le bonheur. De façon générale mon point de vue est "sudo MUST DIE"..
[^] # Re: Qu'est-ce que le principe de précaution ?
Posté par Jerome Herman . En réponse au journal [HS] Pour en finir avec le réchauffement climatique anthropique.... Évalué à 2.
Comme je suis le bien involontaire auteur de ce troll, je permettrais juste un commentaire :
Je ne connais pas à fond la théorie des cordes (loin de là) mais il me semble que les paramètres sont pour la plupart inter compensés (i.e : il est difficile d'invalider complètement les valeurs d'un paramètre, car on peut corriger un modèle contredit par l'expérience en faisant varier les autres)
De fait on ne peut invalider complètement des pans entiers de la théorie, juste des tuples de plages de paramètres.
En invalidant une théorie par seconde il faut quand même plus de 3*10⁴⁹² années pour évacuer la théorie des cordes.
C'est combien déjà la durée de vie de l'univers ?