Protéger des dossiers par mot de passe

latino973

Membre confirmé
18 Juin 2010
53
1
54
Bonjour,
Je voudrais savoir s'il existe une application sous Lion dans le MacStore qui me permettrai de protéger un dossier ou une application avec un mot de passe comme le fait iProtect ou lockdown pro sur les iPhone et iPad ,
Merci d'avance pour vos retours
 
Peut tu me donner plus d'explication STP, merci
 
Un petit extrait des nombreuses réponses qu'on peut obtenir en faisant une recherche sur le forum avec les mots clés "+protéger +dossier +passe" : ce fil, celui-là, il y en a un sacré paquet. A priori, tu devrais y trouver ton bonheur et, si jamais tes exigences sont différentes de ce qui a été évoqué, précise en quoi.
 
  • J’aime
Réactions: Powerdom
Et une fois de plus, on va le répéter : la gestion de différents comptes utilisateur est faite pour que les autres utilisateurs n'aillent pas fouiller dans tes affaires. :siffle: Il va falloir qu'un jour Apple se décide à communiquer sur cette notion qui semble totalement ignorée de la grande majorité des utilisateurs de Mac. C'était bien la peine de passer à UNIX :rateau:
 
Et donc un mot de passe sur ta session et le tour est joué. tous les dossiers seront protégés ! ;)
 
Quelqu'un peut-il me dire s'il est possible - et si oui comment... - de protéger certains dossiers par mot de passe dans ma session utilisateur (étant administrateur de l'ordi), afin d'en empêcher l'accès quand ma session reste ouverte ?
Merci.
Stradefi
 
Merci !
Je n'avais pas trouvé ici, mais je viens de dégoter ça sur youtube, très utile : http://www.youtube.com/watch?v=AlMshR5Ini0
Merci pour le fil de discussion ! ;)

tout ce qui est dans la vidéo est expliqué dans la discussion sus-citée ;)

bonne journée


-----------------------------------------------
Note du modérateur-squatteur (ici Aliboron) :

Pour simplifier tout ça, on fusionne !

 
Dernière édition par un modérateur:
Le Francophone à l'accent traînant de la vidéo de YouTube n'a oublié qu'un détail pourtant crucial : c'est que les dossiers protégés en Lecture/Écriture sont susceptibles de grandir en taille. La méthode de l'Image-Disque de Dossier, génératrice d'un .dmg, ne permet la création que d'une image-disque de taille strictement équivalente d'entrée à celle du dossier concerné, et donc insusceptible d'augmentation si l'on fait jouer la faculté pré-définie d'écriture.

Il s'agit donc, comme on dit, d'une contradiction in adjecto.

La méthode pertinente n'est donc pas celle-là [désolé si macomaniac fait encore la preuve ici de son esprit d'alambiquage :D], mais au contraire celle qui passe par la création d'une image de faible densité, dite SPARSEIMAGE, dont la caractéristique essentielle consiste dans le différentiel entre la taille potentielle et la taille actuelle. La taille potentielle désigne la capacité limite qui est choisie à l'origine pour un fichier .sparseimage (on peut sans aucun inconvénient la choisir extrêmement élevée, genre : 100 GO!) ; la taille actuelle est le poids par défaut de l'image-vide, qui est d'environ 3% de la taille potentielle (300 MO pour 100 GO) + le seul poids actuel des fichiers enregistrés sur le disque-image. Exemple : j'ai fait 'écrire' un film de 1,45 MO sur mon disque-image : il pèse donc 1,45 GO + 300 MO = 1,75 GO pour 100 GO de taille potentielle dont la capacité inemployée ne pèse rien ; j'ai fait 'écrire' une série de films qui équivalent à 45 GO. Mon disque-image .sparseimage pèse actuellement 45 GO + 300 MO = 45,3 GO.

Ce qui signifie : la taille potentielle ne pèse rien par elle-même, excepté les 3% de sa capacité virtuelle que la création du fichier .sparseimage doit acquitter d'entrée = la «Tare» du fichier ; c'est la taille actuelle des fichiers qu'i y sont écrits qui définit le poids réel de la .sparseimage = le «Lest» du fichier. Une .sparseimage ne pèse donc jamais que la somme de la Tare initiale et du Lest actuel.

2 visuels pour décrire le procédé :

217047_original.jpg


217176_original.jpg

En résumé : il est absolument crucial de créer des .sparseimage et pas des .dmg, dès lors qu'on envisage une écriture ouverte dans l'espace constitué, càd. ce qu'on appelle des images extensibles. Dès que l'apport d'écriture est volumineux, par exemple si l'on gère des fichiers-vidéos ou même des fichiers-images, le format .sparseimage (image extensible de faible densité actuelle relativement à sa capacité potentielle) est incontournable, n'en déplaise à notre démonstratif Francophone et quitte à macomaniac d'avoir une énième fois alambiqué comme à plaisir :D
 
Dernière édition par un modérateur:
Il me semblait que la différence entre une sparseimage et un .dmg était que le .dmg prend la totalité de l'espace tout de suite (même si le .dmg est vide), alors que la sparseimage ne prendra la totalité de l'espace que lorsqu'elle sera pleine.

Mais dans les deux cas, on doit définir une taille maximale de fichier, qui ne pourra être dépassée (si on a mal évalué la taille, il suffira de créer une nouvelle image et de copier de l'ancienne image vers la nouvelle).
 
En complément au brillant exposé ci-dessus, je ferais deux petites suggestions :
- éviter que l'image disque ne devienne trop importante
- bien sauvegarder des états valides de l'image disque

Parce que, quand elle ne va plus bien, l'image disque devient inutilisable, impossible à ouvrir, kaput etc.
[cf. tous les malheureux ayant eu des déboires avec Filevault].
Par exemple, si un des secteurs sur lesquels l'image disque est stockée devient défectueux, l'ensemble d'icelle sera perdu.

Donc : on redouble de précaution ! [je suppose que si on met quelque chose dans une image disque chiffrée, c'est qu'on y tient un peu plus qu'à ce qu'on n'y met pas... ;) ]

PS : j'aime bien le mot "alambiqué", qui me ramène à certaines lectures de jeunesse [et encore de maintenant, de fait] avec le héros couillonnissime d'une bande dessinée belge sympathique.
 
En complément au brillant exposé ci-dessus, je ferais deux petites suggestions :
- éviter que l'image disque ne devienne trop importante
- bien sauvegarder des états valides de l'image disque

Parce que, quand elle ne va plus bien, l'image disque devient inutilisable, impossible à ouvrir, kaput etc.
[cf. tous les malheureux ayant eu des déboires avec Filevault].
Par exemple, si un des secteurs sur lesquels l'image disque est stockée devient défectueux, l'ensemble d'icelle sera perdu.

Donc : on redouble de précaution ! [je suppose que si on met quelque chose dans une image disque chiffrée, c'est qu'on y tient un peu plus qu'à ce qu'on n'y met pas... ;) ]
+1

PS : j'aime bien le mot "alambiqué", qui me ramène à certaines lectures de jeunesse [et encore de maintenant, de fait] avec le héros couillonnissime d'une bande dessinée belge sympathique.
j'y ai immediatement pensé aussi , Jerome , Sidonie etc
 
:coucou: Sly.

Tu as entièrement raison. Le .dmg prend d'emblée en poids réel l'équivalent de la taille totale qui lui a été assiguée à sa création, quand bien même l'image est vide. Alors que la .sparseimage ne prend d'emblée que la «Tare», càd. environ 3% de la capacité virtuelle qui lui a été assignée.

Je trouve que c'est un énorme avantage dès lors qu'on envisage non pas un contenu constant des données supportées par un disque-image, mais au contraire un contenu évolutif.

Car un .dmg, s'il n'a pas été choisi trop volumineux, afin de ne pas prendre d'entrée tout l'espace d'une capacité prédéfinie très lourde, va vite craquer aux coutures en cas d'apport de fichiers volumineux, et il faudra re-créer un nouveau .dmg plus grand, qui là encore va d'entrée prendre tout l'espace de la taille prédéfinie. Il y a donc toujours une perte d'espace actuel, couplée à une capacité-limitée qui ne se surmonte que par destruction et recréation du .dmg. Si par contre le .dmg est choisi très volumineux pour éviter ces manipulations de destruction et recréation, eh bien! c'est le problème que tu soulevais : il va prendre d'entrée en poids actuel tout l'espace de sa capacité prédéfinie, et ça va peser un max.

Ce n'est pas du tout la limitation de la .sparseimage. Car on peut lui prédéfinir une ample capacité, qui ne pèsera jamais plus que la tare, c'est-à-dire un pourcentage de ce volume virtuel finalement assez faible (3%). Et donc, le poids prédominant de la .sparseimage s'indexera toujours sur le poids actuel des fichiers qu'elle contient et gonflera uniquement avec leur incrémentation, jusqu'à l'atteinte éventuelle de la capacité-limite.


:coucou: bompi.

ditto pour tout, y compris le «couillonnissime» :D


:coucou: Pascal

217779_original.jpg

:D
 
Dernière édition par un modérateur:
et le plus simple est de protéger la session par un mot de passe d'ouverture exigé et une sortie de veille demandant également le mot de passe

Quand on quitte son ordi, on le passe en veille (avec un coin actif de l'écran) ou on ferme la session (cmd-shift-Q)
 
Attention à un detail
une sparseimage va augmenter à l'ajout de contenu
mais quand on enleve du contenu la taille ne diminue pas toujours
 
Attention à un detail
une sparseimage va augmenter à l'ajout de contenu
mais quand on enleve du contenu la taille ne diminue pas toujours

Je dirais même plus : elle ne peut jamais diminuer relativement au maximum de poids réel qui a été atteint à un moment donné. Exemple : supposons une .sparseimage de 100 GO de capacité virtuelle. «Tare» (3%) = 300 MO de poids par défaut. Je l'ai créée pour stocker des vidéos, supposons. À force d'ajouter des fichiers, j'ai atteint 85 GO de vidéos + 300 MO de tare = 85,3 GO de maximum de poids réel. On se rapproche tellement de la limite de capacité (reste 15 GO) que je décide de 'dégraisser'. J'enlève 40 GO de vidéos. Ma .sparseimage récupère un potentiel de stockage de 100 GO - 45,3 GO = 54,7 GO. Mais son poids réel reste bloqué à 85,3 GO.

C'est le paradoxe d'une image-disque extensible qui pèse plus qu'elle n'a d'espace réellement occupé. Et tant que les vidéos que je rajouterai derechef ne viendront occuper que les 40 GO d'espace de stockage libéré, le poids de ma .sparseimage n'augmentera pas d'un iota, mais restera bloqué à 85,3 GO, càd. son maximum de poids réel atteint une fois (pour rester dans l'esprit Belge). Au-delà de 40 GO, toute vidéo supplémentaire ajoutera le strict équivalent de son poids aux susdits 85,3 GO.
 
Dernière édition par un modérateur: