Je trouve finalement étonnant que tout le monde s'accomode ici sans
râler d'insuffisances franchement désolantes de certaines applis livrées
avec Mac OS X, et je me dis que si on n'en parle pas sur les groupes, ça
va finir par laisser penser à Apple qu'il n'y a rien d'urgent à faire
dans ce domaine !
Parce que, de vous à moi :
- Avec toutes les qualités que je veux bien lui reconnaître, ne
trouvez-vous pas qu'AppleWorks commence à sentir un peu le moisi, ne
serait-ce qu'au niveau de l'apparence ?
- L'impossibilité dans ce logiciel comme dans Carnet d'adresse de
pouvoir imprimer des étiquettes à l'unité en partant d'une planche déjà
entammée (à l'étiquette "x") comme savait déjà le faire JoliPhone/Carnet
il y a plus de dix ans, ça ne vous semble pas du gâchis ?
- L'impossibilité de choisir les polices de caractère (et surtout leur
taille) dans iCal, que ce soit à l'écran ou à l'impression (et surtout
indépendamment l'une de l'autre) ne vous semble-t-elle pas gavante et
sérieusement limitante ?
- L'impossibilité d'utiliser le "fabuleux" AirTunes avec autre chose que
iTunes, et en particulier sa non-intégration dans le système pour
diffuser simplement le son d'une séquence QuickTime, en principe
pourtant intégré très "bas" dans le système... c'est pas un peu la haine
et prendre les gens pour des khons ?
- L'impossibilité pour Apple Remote Desktop d'accéder à une session
ouverte en arrière-plan et son incapacité à gérer autre chose que ce qui
est affiché à l'écran du poste distant ne constitue-t-elle pas une
limitation très dommageable de ce logiciel ? (par rapport au
fonctionnement multi-utilisateur de Mac OS X par ailleurs !).
- et finalement est-il si normal que cela que le mode "Target" de boot
en disque cible donne accès à l'ensemble du disque interne sans tenir
aucun compte des autorisations de ses dossiers ?
Je tiens pour possible d'avoir éventuellement faux sur un point ou un
autre, et serais heureux qu'on me sorte alors de l'erreur ! Sinon il y a
du boulot à abattre pour Tiger !
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après
changement du mot de passe) n'est pas le problème : c'est le but même du
mot de passe principal ! Par contre, puisque : 1) on peut monter l'image
avec le mot de passe du compte, et 2) le mot de passe principal est tout
ce qui est nécessaire pour accéder au compte, ça signifie que le mot de
passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si
ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <1gn8n17.56q5un1oxckj1N%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
Patrick -- Patrick Stadelmann
In article <1gn8n17.56q5un1oxckj1N%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après
changement du mot de passe) n'est pas le problème : c'est le but même du
mot de passe principal ! Par contre, puisque : 1) on peut monter l'image
avec le mot de passe du compte, et 2) le mot de passe principal est tout
ce qui est nécessaire pour accéder au compte, ça signifie que le mot de
passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si
ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gn8n17.56q5un1oxckj1N%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
La question reste quand même : y accède-t-il ou le change-t-il ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
La question reste quand même : y accède-t-il ou le change-t-il ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
La question reste quand même : y accède-t-il ou le change-t-il ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <1gn8olh.1z0ww3j1b0j5p7N%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Patrick -- Patrick Stadelmann
In article <1gn8olh.1z0ww3j1b0j5p7N%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gn8olh.1z0ww3j1b0j5p7N%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
Euh, un moyen d'y accéder ou de le changer ?
D'y accéder.
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <1gnbdwx.1nzx0em9i1xmoN%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Patrick -- Patrick Stadelmann
In article <1gnbdwx.1nzx0em9i1xmoN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est
faisable.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gnbdwx.1nzx0em9i1xmoN%, (Laurent Pertois) wrote:
Patrick Stadelmann wrote:
La question reste quand même : y accède-t-il ou le change-t-il ?
Il l'accède.
Tu as vérifié ?
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que le changer et donc détruire l'accès à la keychain (si on n'a pas mis de mdp différent de celui du login sur cette dernière), il pourrait proposer de l'afficher après avoir entré le mot de passe principal.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est
faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que
le changer et donc détruire l'accès à la keychain (si on n'a pas mis de
mdp différent de celui du login sur cette dernière), il pourrait
proposer de l'afficher après avoir entré le mot de passe principal.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que le changer et donc détruire l'accès à la keychain (si on n'a pas mis de mdp différent de celui du login sur cette dernière), il pourrait proposer de l'afficher après avoir entré le mot de passe principal.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Schmurtz
(Laurent Pertois) wrote:
Patrick Stadelmann wrote:
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que le changer et donc détruire l'accès à la keychain (si on n'a pas mis de mdp différent de celui du login sur cette dernière), il pourrait proposer de l'afficher après avoir entré le mot de passe principal.
L'OS le déchiffre forcément parce qu'il en a besoin pour décrypter l'image disque (qui n'est décrytable qu'avec ce mot de passe). Apple à décider de ne pas afficher le mot de passe à l'écran par ce que 1) c'est pas utile, 2) c'est dommage de dévoiler aussi simplement le mot de passe.
Il y a peut-être une petite chance que l'MacOS X ne décrypter pas le mot de passe : s'il stocke la clef de crytage qui sert à crypter l'image disque (elle même crypter par le mot de passe utilisateur et stocké dans l'image disque).
Une vérification utile à faire : ce Master Password modifie-t'il aussi le mot de passe du trousseau d'accès par défaut ? Si oui, on peut être sûr de MacOS X décrypte le mot de passe utilisateur avec le Master Password.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est
faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que
le changer et donc détruire l'accès à la keychain (si on n'a pas mis de
mdp différent de celui du login sur cette dernière), il pourrait
proposer de l'afficher après avoir entré le mot de passe principal.
L'OS le déchiffre forcément parce qu'il en a besoin pour décrypter
l'image disque (qui n'est décrytable qu'avec ce mot de passe). Apple à
décider de ne pas afficher le mot de passe à l'écran par ce que 1) c'est
pas utile, 2) c'est dommage de dévoiler aussi simplement le mot de passe.
Il y a peut-être une petite chance que l'MacOS X ne décrypter pas le mot
de passe : s'il stocke la clef de crytage qui sert à crypter l'image
disque (elle même crypter par le mot de passe utilisateur et stocké dans
l'image disque).
Une vérification utile à faire : ce Master Password modifie-t'il aussi
le mot de passe du trousseau d'accès par défaut ? Si oui, on peut être
sûr de MacOS X décrypte le mot de passe utilisateur avec le Master
Password.
Non. Mais si l'OS sait décrypter le mot de passe, c'est que c'est faisable.
Comment être sûr qu'il le déchiffre ? parce que dans ce cas, plutôt que le changer et donc détruire l'accès à la keychain (si on n'a pas mis de mdp différent de celui du login sur cette dernière), il pourrait proposer de l'afficher après avoir entré le mot de passe principal.
L'OS le déchiffre forcément parce qu'il en a besoin pour décrypter l'image disque (qui n'est décrytable qu'avec ce mot de passe). Apple à décider de ne pas afficher le mot de passe à l'écran par ce que 1) c'est pas utile, 2) c'est dommage de dévoiler aussi simplement le mot de passe.
Il y a peut-être une petite chance que l'MacOS X ne décrypter pas le mot de passe : s'il stocke la clef de crytage qui sert à crypter l'image disque (elle même crypter par le mot de passe utilisateur et stocké dans l'image disque).
Une vérification utile à faire : ce Master Password modifie-t'il aussi le mot de passe du trousseau d'accès par défaut ? Si oui, on peut être sûr de MacOS X décrypte le mot de passe utilisateur avec le Master Password.
-- Schmurtz
Paul Gaborit
À (at) Fri, 12 Nov 2004 16:11:55 +0100, Patrick Stadelmann écrivait (wrote):
In article , Paul Gaborit wrote:
Oui. Si l'utilisateur oublie ce mot de passe, tout est perdu.
Non, justement le Master Password sert justement à éviter cela.
Mais qu'appellez-vous le "master password" ? D'après ce que vous proposez ensuite (deux chiffrages du mot de passe de l'archive filevault), vous supposez qu'il existe un mot de passe (master password?) global à la machine. Cela n'existe pas.
Si, on le règle dans les préférences système, sous Sécurité. En français il s'appelle "mot de passe principal".
Merci pour cette info... Comme je n'utilise pas FileVault, je n'avais pas eu à régler cela. C'est un modèle de sécurité qui me semble un trop centralisé mais pourquoi pas. Si on doit gérer 700 personnes avec cela, il faut déranger le détenteur de ce fameux mot de passe à chaque fois qu'un utilisateur oublie son mot de passe. On aurait pu imaginer un truc un tout petit peu plus distribué (à deux niveaux par exemple). D'un autre côté, pour une petite organisation, ça a le mérite d'être simple.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 12 Nov 2004 16:11:55 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
In article <r7bre3i0v5.fsf@pasteur.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Oui. Si l'utilisateur oublie ce mot de passe, tout est perdu.
Non, justement le Master Password sert justement à éviter cela.
Mais qu'appellez-vous le "master password" ? D'après ce que vous proposez
ensuite (deux chiffrages du mot de passe de l'archive filevault), vous
supposez qu'il existe un mot de passe (master password?) global à la
machine. Cela n'existe pas.
Si, on le règle dans les préférences système, sous Sécurité. En français
il s'appelle "mot de passe principal".
Merci pour cette info... Comme je n'utilise pas FileVault, je n'avais pas eu à
régler cela. C'est un modèle de sécurité qui me semble un trop centralisé mais
pourquoi pas. Si on doit gérer 700 personnes avec cela, il faut déranger le
détenteur de ce fameux mot de passe à chaque fois qu'un utilisateur oublie son
mot de passe. On aurait pu imaginer un truc un tout petit peu plus distribué
(à deux niveaux par exemple). D'un autre côté, pour une petite organisation,
ça a le mérite d'être simple.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 12 Nov 2004 16:11:55 +0100, Patrick Stadelmann écrivait (wrote):
In article , Paul Gaborit wrote:
Oui. Si l'utilisateur oublie ce mot de passe, tout est perdu.
Non, justement le Master Password sert justement à éviter cela.
Mais qu'appellez-vous le "master password" ? D'après ce que vous proposez ensuite (deux chiffrages du mot de passe de l'archive filevault), vous supposez qu'il existe un mot de passe (master password?) global à la machine. Cela n'existe pas.
Si, on le règle dans les préférences système, sous Sécurité. En français il s'appelle "mot de passe principal".
Merci pour cette info... Comme je n'utilise pas FileVault, je n'avais pas eu à régler cela. C'est un modèle de sécurité qui me semble un trop centralisé mais pourquoi pas. Si on doit gérer 700 personnes avec cela, il faut déranger le détenteur de ce fameux mot de passe à chaque fois qu'un utilisateur oublie son mot de passe. On aurait pu imaginer un truc un tout petit peu plus distribué (à deux niveaux par exemple). D'un autre côté, pour une petite organisation, ça a le mérite d'être simple.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Sun, 14 Nov 2004 10:33:20 +0100, Patrick Stadelmann écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc considérer que le mot de passe de l'utilisateur est moins bien protégé ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault est crypté avec un clef choisie au hasard et que c'est uniquement cette clé qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe principal. En tous cas, cela correspondrai mieux aux critères habituels de sécurité.
Ceci étant, je ne connais pas les choix faits par Apple.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Sun, 14 Nov 2004 10:33:20 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après
changement du mot de passe) n'est pas le problème : c'est le but même du
mot de passe principal ! Par contre, puisque : 1) on peut monter l'image
avec le mot de passe du compte, et 2) le mot de passe principal est tout
ce qui est nécessaire pour accéder au compte, ça signifie que le mot de
passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si
ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc
considérer que le mot de passe de l'utilisateur est moins bien protégé
ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault
est crypté avec un clef choisie au hasard et que c'est uniquement cette clé
qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe
principal. En tous cas, cela correspondrai mieux aux critères habituels de
sécurité.
Ceci étant, je ne connais pas les choix faits par Apple.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Sun, 14 Nov 2004 10:33:20 +0100, Patrick Stadelmann écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc considérer que le mot de passe de l'utilisateur est moins bien protégé ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault est crypté avec un clef choisie au hasard et que c'est uniquement cette clé qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe principal. En tous cas, cela correspondrai mieux aux critères habituels de sécurité.
Ceci étant, je ne connais pas les choix faits par Apple.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
