The changes are intended to revive an important security concept that has been a low priority among many Windows users and application developers.
"I don't think the notion of application runtime permissions are either well understood or well handled," said Jason Rimmer, chief architect at Vertex Inc., a tax technology and services provider based in Berwyn, Pennsylvania. "Coming from Unix, you're used to asking 'Does this run under root or not?' But Windows operators have never had to consider that. LUA will force that choice on people," he said.
Cependant, cela va obliger à modifier moult applications afin d'être LUA compliant : Least-Privilege User Account
Microsoft declined repeated invitations to discuss LUA's role in upcoming Longhorn releases, but says it is considering LUA for future releases as part of an overall vision for multilayered security known as "defense in depth," according to an e-mail statement attributed to Amy Roberts, director of the Security Business and Technology Unit at Microsoft.
Alors, cet info ? Un fake ou une réalité ? Et si c'est le cas, comment les ingénieurs de Microsoft l'implémenteront-ils ? [2]
Too bad "MS-root" can't watch over your grandmother when she opens emails."
[1] http://www.pcworld.com/resource/article/0,aid,120314,pg,1,RSS,RSS,0(...)
[2] http://it.slashdot.org/article.pl?sid=05/04/08/147237&from=rss(...)
# Ce que j'ai compris
Posté par Matthieu . Évalué à 10.
Le problème sous Windows est que lorsque vous voulez installer puis utiliser un programme vous devez dans 90% des cas avoir des droits administrateurs. Pourquoi ? parce que des données utilisateurs sont copiées dans l'espace OS (données utilisateurs dans program files, ou dans la base de registre). C'est stupide, ils viennent de s'en rendre compte. Il n'est jamais trop tard pour changer.
Au final, ils veulent imposer un nouveau (pour eux) concept qui est le LUA, soit le fait qu'un programme doit avoir le moins de droit possible, juste le strict nécessaire. Ils (Microsoft) reflechissent donc à la norme LUA (y'aura des logos pour les programmes qui respectent la norme). De plus, ça permettra (disent-ils) de faire baisser le nombre de virus, car les pirates utilisent le fait qu'un utilisateur a des droits administrateurs sur sa machine (sinon il ne pourrait utiliser aucune application, quoi seulement 10%).
Voila. c'est ce que j'ai compris vite fait.
Ce qui me fait marrer, c'est que les gens vont croire que Microsoft vient d'avoir une idée de génie, vont se faire embobiner par une campagne médiatique, alors que c'est un concept de base de la sécurité, connu depuis des lustres.
# plagiat ?
Posté par plagiats . Évalué à 10.
[^] # Re: plagiat ?
Posté par Gniarf . Évalué à 4.
[^] # Re: plagiat ?
Posté par plagiats . Évalué à 1.
# j'aimes pas les titres
Posté par pasBill pasGates . Évalué à 2.
Les droits sous Windows ca existe depuis la 1ere version de NT en 1992.
LUA c'est lie, mais c'est autre chose(et non, je peux pas en dire plus)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: j'aimes pas les titres
Posté par pasBill pasGates . Évalué à -1.
Non, ca veut dire ce que cette feature est liee au fait que les applis ne sont pas sensees tourner avec tous les privileges, mais cette feature ce n'est pas le systeme de droits lui-meme.
[^] # Re: j'aimes pas les titres
Posté par Richard Hébert (site web personnel) . Évalué à 3.
lie, mentir, toussa ...
[^] # Re: j'aimes pas les titres
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
[^] # Re: j'aimes pas les titres
Posté par Pior . Évalué à -3.
Je n'ai jamais répondu à tes pseudos "réponses" de la firme mais là c'est trop.
Au lieu de mettre en avant une *bonne* avancé de windows (la LUA) tu essayes de faire croire que quelqu'un a cru à une absence de droit dans windows...
Vraiment je me demande combien de temps on va devoir supporter tes pitoyables interventions.
Quand j'ai compris qu'une personne de Microsoft intervenait ici, je me suis dit que ce serait pas mal. Le risque que la communauté se referme sur elle même est grand, une "réponse honnête et constructive" aurait pu être interessante.
Mais là ! C'est raté ! Ne me réponds pas que certains commentaires ici, sont pires que les tiens : c'est une communauté : il y a du bien et du moins bien.
Mais si toi tu joue à ça, alors c'est pas la peine de poursuivre.
Peux être trouves-tu celà amusant ? Ou bien les cadres sup chez MS s'embètent à ce point là ? (note la pointe ironique)
Pour finir, j'espère que tu ne me répondras pas pBpG, tu utiliserais une technique à la noix qui finirait bien par irriter quelqu'un, qui perdrait du temps à te répondre...
# ACL
Posté par ckyl . Évalué à 6.
Repond pas ca pourrait faire mal :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ACL
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
- nfs ne les supporte pas (en tout cas chez moi)
- tar non plus (star oui)
- rsync n'en tient pas compte (unison nnon plus)
- ...
Bref, ca marche effectivement en local sur une machine ;-)
[^] # Re: ACL
Posté par Médéric RIBREUX (site web personnel) . Évalué à 2.
Je l'utilise en prod depuis 2 mois sur mon serveur bureautique Samba3. C'est vrai que comparé aux droits NT, il y a moins de détails mais ça reste largement fonctionnel.
[^] # Re: ACL
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je suis d'accord avec un un post ci-dessus. Au niveau des droits, il manque quelques reglages ici ou là. Par exemple, le nombre de groupe par personne est limité (par nfs notament) et il n'est pas possible de faire de l'imbrication de groupe. Dans la plupart des cas, une meilheure gestion des groupes suffirait.
[^] # Re: ACL
Posté par gnujsa . Évalué à 2.
[^] # Re: ACL
Posté par ckyl . Évalué à 5.
Deux exemple simple :
- Tu es dans une université tu as ton uid et ton gid. Toute ta promo à le même gid. Maintenant tu m'expliques comment tu partages un repertoire avec tes binômes.
- Tu es un utilisateur lambda qui veut que dans sont ~/public_html les fichiers soient automatiquement accessibles pour apache. Explique moi comment tu fais ca *simplement* sans ACL et sans mettre tout tes fichiers en 644.
Les droits UNIX c'est un peu comme le principe du root : depassé. Ils ne suffisent clairement pas. Il serait temps d'arrêter la stagnation ambiente, et le pire c'est que les solutions existent.
Et comme tu le signales Gnome ne connait absolument pas le principe d'ACL (pour répondre au post un peu au dessus). Les ACL sont par *defaut* dans linux depuis le 2.6, ne sont toujours pas dans les coreutils faut toujours un patch dont on ne sait même plus la provenance et qui le maintient, les interfaces graphiques ne permettent pas de les manipuler et encore pire d'afficher correctement les permissions.
[^] # Re: ACL
Posté par salvaire . Évalué à 3.
Dans ce cas. Tu utilise uniquement les ACL sur les systèmes de fichiers partagés et en réseaux (/afs par exemple). Pour le reste (/...) les droits unix sont idéale, simple et rapide.
[^] # Re: ACL
Posté par Matthieu . Évalué à 4.
Bah tu ferais comment sous windows ?
Moi sous Linux, je rajouterais un groupe pour le binome et changement l'appartenance du répertoire au groupe créé.
- Tu es un utilisateur lambda qui veut que dans sont ~/public_html les fichiers soient automatiquement accessibles pour apache. Explique moi comment tu fais ca *simplement* sans ACL et sans mettre tout tes fichiers en 644.
Est-ce vraiment gênant de donner les droits de lecture pour tout le monde pour des fichiers que tu publie à tout le monde ?
Si ça te gêne, tu mets le groupe owner de tes fichiers au groupe apache (chown .apache ~/public_html -R) et tu donnes les droits +r au groupe et rien pour other.
Les droits UNIX c'est un peu comme le principe du root : depassé.
Encore une affirmation non argumentée. Tu m'explique en quoi le principe du root est dépassé ?
[^] # Re: ACL
Posté par pasBill pasGates . Évalué à 10.
Sous Windows tu rajoutes simplement le droit en lecture a ton binome, tu n'as rien besoin d'enlever aux permissions existant sur le repertoire et un simple utilisateur peut le faire.
Moi sous Linux, je rajouterais un groupe pour le binome et changement l'appartenance du répertoire au groupe créé.
Comment fais tu, toi simple etudiant qui n'a pas d'acces root pour ajouter un groupe au systeme ?
Est-ce vraiment gênant de donner les droits de lecture pour tout le monde pour des fichiers que tu publie à tout le monde ?
Oui, car ils se pourrait que tu mettes un controle d'acces dans Apache lui-meme, resultat tu veux que ces fichiers soient lisibles par Apache seulement, et Apache decide qui a droit a quel fichier.
Si ça te gêne, tu mets le groupe owner de tes fichiers au groupe apache (chown .apache ~/public_html -R) et tu donnes les droits +r au groupe et rien pour other.
Ce n'est rien d'autre qu'un hack boiteux, ca t'empeche de donner acces au fichier a un groupe de personnes, c'est soit le groupe de personnes, soit Apache.
[^] # Re: ACL
Posté par Matthieu . Évalué à 2.
Pour le second, que tu dis que c'est un hack boiteux, je ne suis pas d'accord du tout. La philosophie est comme ça, tu ne peux pas dire que c'est un hack, sinon je ne vois pas en quoi l'appartenance d'un fichier à un groupe servirait si ce n'est faire des hacks boiteux.
[^] # Re: ACL
Posté par pasBill pasGates . Évalué à 4.
Oui la philosophie est comme ca, et l'appartenance d'un fichier a un groupe n'est pas un hack boiteux en elle meme, simplement, cette philosophie ne repond plus aux besoins d'aujourd'hui ou tu as besoin d'une granularite plus fine et plus de flexibilite dans les permissions. C'est pour ca que je dis que ta proposition est un hack boiteux, tu essaie de faire faire qqe chose a un systeme qui n'a pas ete prevu pour ca. Ca marchera un petit moment, et des que la situation changera un petit peu, paf tu seras dans la mouise car ton hack n'etait qu'un bandage sur une plaie ouverte.
[^] # Re: ACL
Posté par ckyl . Évalué à 4.
Voir réponse de pbpg
> Moi sous Linux, je rajouterais un groupe pour le binome et changement
Chez moi les étudiants n'ont pas d'accès root.
De plus ce n'est que reculer pour mieux sauter le nombre de groupes auxquels peut appartenir un utilisateur se trouve entre 8 et 64.
Si on calcul grosso modo sachant qu'un etudiant à 5 projets par semestre sur une promo de 100 personnes ca fait dans les 5 * 50 = 250 groupes. Ici y'a facilement entre 500 et 1000 personnes je sens que l'admin va aimer ta solution :-)
> Est-ce vraiment gênant de donner les droits de lecture pour tout le monde pour des fichiers que tu publie à tout le monde ?
Ce n'est pas la question. Ma mère ne sait pas ce qu'est une permission sur un fichier. Le ~ de ma mère ne doit pas être en 755/644. Le ~/public_html doit être lisible par apache sans avoir à faire de chmod à la main. Hormis un hack affreux à coup de cron tu ne peux pas sans ACL.
Tu adaptes la question pour qu'elle corresponde à ta reponse. Je ne sais pas si c'est conscient ou non.
> Tu m'explique en quoi le principe du root est dépassé ?
Tu as vécu dans une cave ces 20 dernières années ? Pourquoi un apache à besoin d'être tout puissant sur la machine alors qu'il veut juste binder le 80 ?
Pourquoi l'administrateur du serveur web/mail peut-il lire les fichiers de tout le monde ?
Pourquoi on introduit du MAC pour résoudre les problèmes du DAC UNIX ? Pourquoi grsec/rbsac/MAC/selinux tentent de limiter les méfaits du root ? Pourquoi depuis quelques années on ne teste plus si l'uid = 0 dans le noyau mais si l'utilisateur à la capability donnée ?
Pourquoi les inventeurs d'UNIX ont fait un nouveau système qui ne refait pas la même erreur ?
Un des grands problèmes à mon sens c'est que de nos jours on semble croire que l'on à LA solution en ce qui concerne les OS. Et on reste figé depuis les années 70 dans la philosophie UNIX persuadée que c'est la bonne. La diversité n'existe plus, linux se doit d'avoir raison. Combien de systèmes inonvants ont vu le jour cette année ?
Si linux à bien fait une chose c'est tuer la diversité des noyaux. L'énorme majorité du travail universitaire est fait sous forme de modification de linux et non plus sous forme de nouveaux systèmes.
http://www.cs.bell-labs.com/who/rob/utah2000.pdf(...)
[^] # Re: ACL
Posté par Matthieu . Évalué à 2.
C'est vrai que à premier abord, sous Unix, la gestion des droits est moins user-friendly et moins puissante que sous windows (je mets entre italique car y'a le revers de la médaille). Moins puissante et moins poussée. Pour commencer, le problème de partage des répertoires pour les binômes existe depuis de nombreuses années, et ce n'est pas un problème qui m'a traumatisé. On s'en est sorti avec des solutions plus ou moins bonne. Mais on en est pas mort.
Ensuite, la gestion des droits sous Windows est certe plus poussée et plus user-friendly, mais le revers de la médaille est que d'un point de vue sécuritaire, et de mon point de vue également, je trouve ça moins sécure. Pourquoi ? de par la compléxité. Je pense que tu ne peux pas avoir un système sécure s'il est trop compliqué à appréhender dans son ensemble. Notre cerveau est limité. Si c'est trop compliqué, ça nous échappe et on fait des bêtises. De plus, quand on a un problème avec des droits sous Windows, et bien, c'est légèrement galère à résoudre au vu de la compléxité : "ça vient d'où ? j'ai les bons droit sur ce répertoire... peut-être le répertoire parent ? t'as regardé dans les droits nfs ?....t'as regardé dans les droits du partage ??...."
Tu as vécu dans une cave ces 20 dernières années ? Pourquoi un apache à besoin d'être tout puissant sur la machine alors qu'il veut juste binder le 80 ?
Non je n'ai pas vécu dans une cave. Et ça ne m'empêche pas de penser que apache n'a pas besoin d'être tout puissant sur la machine pour s'exécuter. Il a juste besoin de droit suffisant au démarrage pour pouvoir utiliser le port 80 qui reste un port privilégié.
Pourquoi l'administrateur du serveur web/mail peut-il lire les fichiers de tout le monde ?
Faut arrêter de dire n'importe quoi. C'est de la mauvaise foi. Si tu ne veux pas que ton administrateur du serveur mail puisse lire les fichiers de tout le monde, tu peux le faire. Suffit de ne pas donner les droits r à other à tes fichiers !
Pourquoi grsec/rbsac/MAC/selinux tentent de limiter les méfaits du root ?
Pour protéger root de lui-même !
Un des grands problèmes à mon sens c'est que de nos jours on semble croire que l'on à LA solution en ce qui concerne les OS.
Heu, c'est un peu normal non ? quand tu développes un OS, tu y met le meilleur que tu penses être. Tu ne va pas dire ; j'ai mis ça, mais c'est nul comme solution !
De plus, ta réflexion est pour tous les OS.
Combien de systèmes inonvants ont vu le jour cette année ?
Faut pas lancer le débat sur l'innovation avec moi, car c'est vraiment le truc qui me dégoute. Quand tu regardes d'autres domaines technologiques, tu te demandes si y'a encore des informaticiens pour faire de l'innovation !
Sur ce domaine, mon idée est simple : le monopole actuel qui existe dans le domaine de l'informatique tue l'innovation.
[^] # Re: ACL
Posté par ckyl . Évalué à 3.
Je vais te decevoir je n'ai jamais utilisé de windows supportant les ACL. Ma seule expérience de Windows c'est un Win98 pendant 6 mois.
> On s'en est sorti avec des solutions plus ou moins bonne. Mais on en est pas mort.
l'exemple du binome est reproductible dans des environements un tantinet plus critique qu'une université. On parle de sécurité la.
> De plus, quand on a un problème avec des droits sous Windows
Je ne parle pas de Windows, je ne sais pas si leur implémentation est, feu, POSIX 1003.1E compliant. Je parle du mécanisme d'ACL que tout le monde utilise même si le standard est passé à la trappe. Si tu n'es pas capable de comprendre comment fonctionne le mécanisme d'héritage des droits, soit tu es incompétant soit ce n'est pas aàtoi de se soucier de ce problème.
> Il a juste besoin de droit suffisant au démarrage pour pouvoir utiliser le port 80 qui reste un port privilégié.
Pourquoi un processus d'apache à la possibilite de lire /dev/kmem ou tout ce qui lui semble bon tout au cours de son exécution ? (apache ne drop pas entièrement ses privilèges puisque ses fils doivent binder le 80)
> C'est de la mauvaise foi. Si tu ne veux pas que ton administrateur du serveur mail puisse lire les fichiers de tout le monde, tu peux le faire. Suffit de ne pas donner les droits r à other à tes fichiers !
L'administrateur mail doit pouvoir relancer l'imap, le pop, le smtp. Pouvoir editer les fichiers de conf, les certificats. Faire joujou avec le spool, voir mettre à jour les softs mail. Si tu veux réellement avoir un admin mail qui puisse faire son boulot sans le root c'est la plaie. Une tonne de setuid, des perms à fixer à la main partout etc.
> Pour protéger root de lui-même !
Ok j'ai compris le niveau... Tu ne semble strictement rien connaitre à ces solutions.
> De plus, ta réflexion est pour tous les OS.
Ma reflection porte sur le fait que l'on pense que la vision d'UNIX est toujours juste. Ton message en est l'exemple typique. La plupart des gens, et moi le premier, ont toujours pensé en terme UNIX. Ils ont appris avec, ils evoluent avec. On ne réfléchit donc plus au problème de base, mais on énonce le problème avec la seule sémantique que l'on connait. Et si cela ne marche pas bha "on en est pas mort".
Comme on dit quand on n'a qu'un marteau tout les problèmes ressemblent à des clous. Il te semble naturel qu'un démon système ait besoin d'être "dieu" sur la machine pour se lancer puis de dropper ses privilèges si bon lui semble. Pour moi c'est une solution naturelle dans un monde qui ne propose pas d'autre alternative. C'est la bonne manière de faire dans le monde UNIX. D'un point de vue philosophique c'est une horreur.
[^] # Re: ACL
Posté par Matthieu . Évalué à 2.
Je ne parle pas de Windows, je ne sais pas si leur implémentation est, feu, POSIX 1003.1E compliant. Je parle du mécanisme d'ACL que tout le monde utilise même si le standard est passé à la trappe. Si tu n'es pas capable de comprendre comment fonctionne le mécanisme d'héritage des droits, soit tu es incompétant soit ce n'est pas aàtoi de se soucier de ce problème.
Faudrait expliquer avant ce que tu entends par mécanisme d'héritage des droits !
L'administrateur mail doit pouvoir relancer l'imap, le pop, le smtp. Pouvoir editer les fichiers de conf, les certificats. Faire joujou avec le spool, voir mettre à jour les softs mail. Si tu veux réellement avoir un admin mail qui puisse faire son boulot sans le root c'est la plaie. Une tonne de setuid, des perms à fixer à la main partout etc.
Explique moi également comment tu comptes t'y prendre avec les ACLs. Du genre, comment tu permets à un utilisateur de mettre à jour les softs mails uniquement (en utilisant deb ou rpm, parce qu'en compilant, c'est pas dur à faire) ?
Ok j'ai compris le niveau... Tu ne semble strictement rien connaitre à ces solutions.
Je passe sur l'insulte du début de phrase, je prends sur moi-même.
Explique moi le reste alors. Je déteste que l'on m'affirme des trucs (même vrais) sans l'expliquer.
Au final, ce que j'en comprends c'est que je suis un admin incompétent, qui ne comprends rien aux problèmes que tu as, et que les autres devraient avoir. Que je suis conformiste et que je ne veux pas changer. oui, non ?
[^] # Re: ACL
Posté par ckyl . Évalué à 4.
Bon on va reprendre les quotes avec l'histoirique donc le contexte.
Sujet 1
toi
Notre cerveau est limité. Si c'est trop compliqué, ça nous échappe et on fait des bêtises. De plus, quand on a un problème avec des droits sous Windows, et bien, c'est légèrement galère à résoudre au vu de la compléxité : "ça vient d'où ? j'ai les bons droit sur ce répertoire... peut-être le répertoire parent ?
Moi
de comprendre comment fonctionne le mécanisme d'héritage des droits
Toi
Faudrait expliquer avant ce que tu entends par mécanisme d'héritage des droits !
Réponse
Lors de la création d'un nouvel objet les permissions appliquées à cet objet dépendent des permissions du parent, un fs étant un arbre.
L'algorithme, très simple au passage, qui détermine les permissions se trouvent dans man 5 acl et [1]. Tu sembles avancer que comprendre le système de permissions est difficile ce qui est faux. L'umask n'a rien de plus simple.
[1] http://wt.xpilot.org/publications/posix.1e/download.html(...)
Sujet 2
Toi
Tu m'explique en quoi le principe du root est dépassé ?
Moi
Pourquoi l'administrateur du serveur web/mail peut-il lire les fichiers de tout le monde ?
Toi
Faut arrêter de dire n'importe quoi. C'est de la mauvaise foi. Si tu ne veux pas que ton administrateur du serveur mail puisse lire les fichiers de tout le monde, tu peux le faire. Suffit de ne pas donner les droits r à other à tes fichiers !
Moi
voir mettre à jour les softs mail. Si tu veux réellement avoir un admin mail qui puisse faire son boulot sans le root c'est la plaie. Une tonne de setuid, des perms à fixer à la main partout etc.
Toi
Explique moi également comment tu comptes t'y prendre avec les ACLs.
Réponse
On parlait du problème du root d'UNIX et de la difficulté d'avoir des admins non tout puissant sur une machine. Quel rapport avec les ACL ? Évidement que ca ne résoud pas le problème puisqu'on ne parlait pas de ca.
Le problème est que le root sous UNIX est omniprésent. Dès que tu veux faire autre chose qu'éditer tes fichiers tu finis par devoir avoir des setuid partout, des fixes crados, des serveurs à qui l'ont donne 100x plus de droits qu'ils n'en ont besoin et qui les rendront si ca leur chante.
> Explique moi le reste alors. Je déteste que l'on m'affirme des trucs (même vrais) sans l'expliquer.
Tu ne connais manifestement même pas les solutions greffées sur les concepts UNIX pour fixer comme on peut les problèmes de sécurités qui n'avait pas été pris en compte lors de la conception. Il me semble que tu n'imagines même pas qu'il puisse y avoir d'autres approches ou que l'outil que l'on te donne actuellement n'est pas parfait et devrait être soit modifié soit changé.
Tu es un admin UNIX je ne dis pas que tu es mauvais admin, ton boulot c'est d'utiliser ce qu'on te donne pour essayer de résoudre les problèmes que tu as. Si tu ne vois pas de problème dans la conception bisounours de la sécurité d'UNIX y'a pas de problèmes tu ne dois pas en avoir les besoins. D'ailleurs on peut considérer que le besoin découle de l'existance de solutions. Tu adaptes tes problèmes pour soit solvables avec ce dont tu disposes.
Je te conseil quand même de la lecture intéressante sur le sujet qui te fera toucher du doigt les problèmes.
Comme je suis gentil, j'ai déjà compulsé un peu de doc pour toi il suffit de fouiller dans:
http://www.madchat.org/sysadm/linux/(...)
http://madchat.org/sysadm/kern/(...)
Et des projets interessant à survoler qui proposent souvent l'explication du pourquoi:
http://www.rsbac.org/why.php(...)
http://www.nsa.gov/selinux/info/faq.cfm(...)
http://www.grsecurity.net/features.php(...) (partie RBAC notament)
http://www.trustedbsd.org/home.html(...)
http://www.trustedbsd.org/docs.html(...)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html(...)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/mac.(...)
http://www.linsec.org/(...)
http://www.isso.sparta.com/opensource/(...) (ancienement les NAIlabs plein de projets interessant)
http://www.isso.sparta.com/research/finished_projects/index.html(...)
Tout ceux là planchent sur comment adapter UNIX pour en faire quelque chose répondant plus aux besoins actuels.
Il existe d'autres systèmes tel que plan9 qui partent sur d'autres concepts, http://www.cs.bell-labs.com/sys/doc/auth.html(...)
Sur ce j'arrête la, la discution est devenue stérile
[^] # Re: ACL
Posté par Matthieu . Évalué à 4.
Oui le concept d'héritage est simple, mais d'expérience sous Windows qui implémente d'une certaine manière, cet héritage, à administrer, c'est l'horreur : on a un répertoire qui a des droits qui viennent dont ne sait où (parents, répertoire lui-même, ntfs, share...). Donc, je suis d'accord pour utiliser les acls, que ça peut nous apporter beaucoup, mais faut faire attention à la manière.
Tu es un admin UNIX je ne dis pas que tu es mauvais admin, ton boulot c'est d'utiliser ce qu'on te donne pour essayer de résoudre les problèmes que tu as. Si tu ne vois pas de problème dans la conception bisounours de la sécurité d'UNIX y'a pas de problèmes tu ne dois pas en avoir les besoins. D'ailleurs on peut considérer que le besoin découle de l'existance de solutions. Tu adaptes tes problèmes pour soit solvables avec ce dont tu disposes.
Je suis un admin qui quand il a un problème essaye de le résoudre en utilisant les briques qui existent, je n'ai pas la prétention de tout refaire ou de proposer des solutions.
De plus, au vu de l'étendu du savoir et des compétences à avoir, on ne peut pas se spécialiser dans tous les domaines. Il faut choisir. J'avoue ne pas être un pro des droits sous Unix, j'utilise la base, j'arrive à m'en sortir comme je peux. Toi tu as étudié le problème, donc tu peux en parler mieux que moi.
Comme je suis gentil, j'ai déjà compulsé un peu de doc pour toi il suffit de fouiller dans:
Merci pour moi et les autres lecteurs, car nous ne sommes pas que tous les deux sur le forum (j'espère)
Sur ce j'arrête la, la discution est devenue stérile
... alors que ça devenait intéressant, on commençait à toucher du concret...
[^] # Re: ACL
Posté par Nicolas Schoonbroodt . Évalué à 2.
Dans ton home, tu crée un répertoire foo, chmod x10 foo (ou x11 suivant les cas), dans foo, tu crée un répertoire bar, avec les droits qui vont biens. Tu mets tes fichiers intéressants dedans. Ensuite, tu donne le chemin (~/foo/bar/) aux gens à qui tu veux partager le contenu. En gros, tout le monde voit ton répertoire ~/foo mais vu qu'on ne peut pas lister son contenu, personne ne peux trouver bar, et son contenu. (bon, la c'est facile, mais imaginez ~/foo/bar/fdkjeDFSEkjzl/fdsjlkezAEARCX/fdjdk/ezr/ par exemple, pour être sur)
(Mais je suis d'accord, ce n'est pas une vrai solution) (j'èspere que je ne me suis pas trompé, je fait ca de tête)
[^] # Re: ACL
Posté par ckyl . Évalué à 2.
On note que cette solution n'est que pour la forme, un ptit finger pour regarder quand le mec est connecté ou simplement tourner la tête pour regarder l'écran d'en face. Un coup d'lsof et bingo.
Enfin bon en même temps on parle de gens qui foutent du NFS sur un réseau publique avec accès aux RJ45 pour tout le monde donc on est plus à ca près :-p
[^] # Re: ACL
Posté par titi toto . Évalué à -2.
j'ai passe l'age d'avoir peur qu'on copie sur moi
[^] # Re: ACL
Posté par ckyl . Évalué à 2.
Maintenant passons à ta réponse qui est totalement à côté de la plaque. Car le problème était bien de partager les fichiers. Si tu désires juste qu'il ait accès un petit mail et c'est bon. Essait voir de partager en écriture qu'on rigole un bon coup. Mais tu fais du logiciel libre et tu t'en fou que tout le monde puisse effacer tes fichiers.
[^] # Re: ACL
Posté par taiwan . Évalué à 1.
Tu donne les droits a ton serveur web .
tu met l utilisateur apache dans tous les groupes qui utilise public_html ?
[^] # Re: ACL
Posté par ckyl . Évalué à 2.
La question est comment faire automatiquement.
Exemple pratique
man setfacl pour plus d'information sur l'algorithme de l'héritage. Les drafts de ce qu'aurait du être POSIX 1003.1E sont dispo http://wt.xpilot.org/publications/posix.1e/download.html(...)
Alors si tu m'expliques que c'est possible avec la sémantique des droits UNIX je t'offre une bière et un mars. Je repète pour la troisième fois le problème n'est pas de donner uniquement l'accès à apache. Je sais très bien que c'est possible même si la technique me semble intrisèquement sale (multiplication des groupes, groupes ayant une semantique utilisateur en réalité), mais ce n'est même pas mon problème
[^] # Re: ACL
Posté par gnujsa . Évalué à 2.
« Monsieur tout le monde » utilise MS Windows, il est loggué en administrateur, et se fout complètement des ACLs. Le « Monsieur tout le monde » du futur, utilisera un UNIX Libre, mais s'en foutra toujours des ACLs.
Le but du concept de « Least-Privilege User Account » n'est pas de protéger les gens entre eux comme dans ton exemple d'université, mais plutôt de protéger les gens contre les défauts de leurs programmes. Dans ce contexte, je vois 2 solutions bien dans l'esprit UNIX, qui ne marche pas trop mal: C'est les permissions et les groupes d'une part (groupe: audio, cdrom, video,etc..) et d'autre part l'utilisation d'un backend minimal pour des opérations qui demandent plus de droit. C'est la manière dont fonctionne les gnome-system-tools ( sauf gnome-system-log malheureusement ). Si je lance users-admin en utilisateur normal, il va me demander un mot de pass, puis lancer uniquement le backend en root. Par contraste si je lance kuser (son équivalent dans le monde KDE) Il ne fonctionnera pas (il ne pourra pas lire /etc/shadow). Je suis donc obligé de le lancer en root (GUI comprise) et avec lui toute une ribambelle de programme qui n'ont absolument pas besoin de ces droits root. ( Attention, c'est juste un exemple, il y a de très bon programme KDE, et des mauvais programmes Gnome).
Bien que je n'ai pas touché à un Windows depuis quelques années, je n'ai pas le souvenir qu'une application me demande mon mot de pass administrateur (Le compte administrateur Windows n'est quand même pas rigoureusement l'équivalent du root UNIX)
Sinon je déplore, moi aussi, que les ACLs et surtout les attributs étendus sont inutilisables (ou presque) sous Linux: nautilus, s'en fout, konqueror s'en fout, et même pire, un simple Drag'n Drop et s'en est fini des ACLs et des xattr. Et même avec coreutils patché, il faut insister: cp -pall. Je n'est trouvé que Rox-filer ( http://rox.sourceforge.net/(...) ) de respectueux avec les ACLs et les attributs étendus ( il les préserve lors d'une copie/déplacement de fichier et se sert même un petit peu des attributs étendus).
Euh... c'est dans le changelog ici:
http://acl.bestbits.at/current/diff/coreutils-5.2.1.tar.gz(...)
Ce sont des gens de chez Suze.
[^] # Re: ACL
Posté par ckyl . Évalué à 2.
Non ce n'est toujours pas mainstream. Je viens de regarder le code des coreutils 5.3 ce n'est toujours pas intégré. Il existe bien des patchs mais c'est la plaie, car ils sont toujours en retard et... qu'il faut patcher. Les coreutils ont bien un problème, il suffit de regarder le nombre de patch appliqués par gentoo ou mandrake. Quand on passe les 30 patchs y'a seurieusement quelque chose qui tourne pas rond :-)
Pour info quand j'avais intégré les ACL dans sourcemage j'avais du mettre à jour le patch sur les 5.2.0 et 5.2.1 car il n'était pas dispo. D'ailleurs si tu trouves un patch pour les 5.3.0...
[^] # Re: ACL
Posté par gnujsa . Évalué à 2.
http://evidence.sourceforge.net/features.html(...)
Il s'agit du Gestionnaire de fichier du futur E17
http://evidence.sourceforge.net/screenshots/info_acl.jpg(...)
Aprés un rapide test, ça marche plutôt pas mal: preservation des acls et EAs lors de la copie (drag'n drop), edition des ACLs et des EAs (lecture/ecriture). Par contre si le fichier n'a pas déjà des ACLs/EAs, on ne peut pas en ajouter: Les onglets ACLs et EAs n'apparaisent pas dans les propriétées du fichier.
# Surcouche ?
Posté par mmMMOoooOMMmm . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.