Il m'est arrivé, plus d'une fois, d'alterer par inadvertance le nom d'un
de mes disques durs.
M'est-il possible (sous OS 10.4.11) de verouiller le nom d'un dossier
(disque) sans verouiller pour autant son contenu?
Merci d'avance
--
Jacek FRYDRYCH
Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom d'un dossier/fichier. On verrouille tout le contenu du dossier d'un seul coup (et donc, au passage, le nom d'un dossier/fichier particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du disque système pas des dossiers du premier niveau ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas
aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom
d'un dossier/fichier. On verrouille tout le contenu du dossier d'un
seul coup (et donc, au passage, le nom d'un dossier/fichier
particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du
disque système pas des dossiers du premier niveau ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom d'un dossier/fichier. On verrouille tout le contenu du dossier d'un seul coup (et donc, au passage, le nom d'un dossier/fichier particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du disque système pas des dossiers du premier niveau ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-Michel_REMOVE
Paul Gaborit wrote:
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la bonne vieille technique du la suppression du droit d'écriture dans le dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL "allow append" ?
-- Nicolas Michel
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la
bonne vieille technique du la suppression du droit d'écriture dans le
dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL
"allow append" ?
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la bonne vieille technique du la suppression du droit d'écriture dans le dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL "allow append" ?
-- Nicolas Michel
Paul Gaborit
À (at) Wed, 10 Dec 2008 08:23:24 +0100, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la bonne vieille technique du la suppression du droit d'écriture dans le dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL "allow append" ?
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 08:23:24 +0100,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la
bonne vieille technique du la suppression du droit d'écriture dans le
dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL
"allow append" ?
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien
modifier de son contenu : on peut modifier le contenu des fichiers et
des dossiers qu'il contient, mais impossible de changer le nom, de
supprimer ou d'ajouter des dossiers ou fichiers.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 08:23:24 +0100, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
Pour verrouiller le nom d'un fichier/dossier, il ne reste donc que la bonne vieille technique du la suppression du droit d'écriture dans le dossier contenant le fichier/dossier. Ça verrouille *tous* les noms !
Mais avec ce système tu peux ajouter des fichiers sans une ACL "allow append" ?
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
laurent.pertois
Paul Gaborit wrote:
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien
modifier de son contenu : on peut modifier le contenu des fichiers et
des dossiers qu'il contient, mais impossible de changer le nom, de
supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable
ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Paul Gaborit
À (at) Wed, 10 Dec 2008 11:17:16 +0100, (Laurent Pertois) écrivait (wrote):
Paul Gaborit wrote:
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le droit d'écriture pour tout le monde dans un dossier (gestion des droits Unix/Posix standard).
Les ACL permettent évidemment une gestion beaucoup plus fine des droits. Mais, à ma connaissance, dans Mac OS X, il n'y a malheureusement pas d'interface graphique pour les configurer.
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix et ACL moins les interdictions posées par les ACL.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 11:17:16 +0100,
laurent.pertois@alussinan.org (Laurent Pertois) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien
modifier de son contenu : on peut modifier le contenu des fichiers et
des dossiers qu'il contient, mais impossible de changer le nom, de
supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le
droit d'écriture pour tout le monde dans un dossier (gestion des
droits Unix/Posix standard).
Les ACL permettent évidemment une gestion beaucoup plus fine des
droits. Mais, à ma connaissance, dans Mac OS X, il n'y a
malheureusement pas d'interface graphique pour les configurer.
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable
ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix
et ACL moins les interdictions posées par les ACL.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 11:17:16 +0100, (Laurent Pertois) écrivait (wrote):
Paul Gaborit wrote:
Non. Une fois un dossier verrouillé en écriture, on ne peut plus rien modifier de son contenu : on peut modifier le contenu des fichiers et des dossiers qu'il contient, mais impossible de changer le nom, de supprimer ou d'ajouter des dossiers ou fichiers.
Tu es sûr avec les ACLs ?
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le droit d'écriture pour tout le monde dans un dossier (gestion des droits Unix/Posix standard).
Les ACL permettent évidemment une gestion beaucoup plus fine des droits. Mais, à ma connaissance, dans Mac OS X, il n'y a malheureusement pas d'interface graphique pour les configurer.
Pour rappel, elles fonctionnent ainsi avec les droits posix :
effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix et ACL moins les interdictions posées par les ACL.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Jacques Perrocheau
In article <1irp49i.185jkxvh5gvypN%, (Laurent Pertois) wrote:
> Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas > aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom > d'un dossier/fichier. On verrouille tout le contenu du dossier d'un > seul coup (et donc, au passage, le nom d'un dossier/fichier > particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du disque système pas des dossiers du premier niveau ;-)
Désolé de jouer les mouches du coche.... ;-)
Mais je viens d'essayer l'idée de Paul, si effectivement elle fonctionne dans une fenêtre du Finder pour les répertoires et fichiers "sous la racine", visiblement le Finder s'en moque pour les noms des icones de volumes qui apparaissent sur le bureau.
En mettant,
drwxr-xr-t 6 root admin 204B Dec 10 15:46 Volumes
pour le point de montage "standard" /Volumes, je peux renommer dans le Finder les noms des icones des volumes apparaissant sur le bureau. Je suis en Mac OS X 10.4.11.
Peut-être faut-il redémarrer, comme sous Windows ? ;-) (je n'ai pas essayé).
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela peut-être risqué. Des fichiers comme: lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym -r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym se créent à chaque démarrage.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1irp49i.185jkxvh5gvypN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
> Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas
> aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom
> d'un dossier/fichier. On verrouille tout le contenu du dossier d'un
> seul coup (et donc, au passage, le nom d'un dossier/fichier
> particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du
disque système pas des dossiers du premier niveau ;-)
Désolé de jouer les mouches du coche.... ;-)
Mais je viens d'essayer l'idée de Paul, si effectivement elle fonctionne
dans une fenêtre du Finder pour les répertoires et fichiers "sous la
racine", visiblement le Finder s'en moque pour les noms des icones de
volumes qui apparaissent sur le bureau.
En mettant,
drwxr-xr-t 6 root admin 204B Dec 10 15:46 Volumes
pour le point de montage "standard" /Volumes, je peux renommer dans le
Finder les noms des icones des volumes apparaissant sur le bureau. Je
suis en Mac OS X 10.4.11.
Peut-être faut-il redémarrer, comme sous Windows ? ;-) (je n'ai pas
essayé).
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela
peut-être risqué. Des fichiers comme:
lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym
-r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym
se créent à chaque démarrage.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1irp49i.185jkxvh5gvypN%, (Laurent Pertois) wrote:
> Heu.. Ça ne verrouille qu'un niveau. Ça ne se propage quand même pas > aux sous-dossiers. Mais, c'est sûr qu'on ne verrouille pas que le nom > d'un dossier/fichier. On verrouille tout le contenu du dossier d'un > seul coup (et donc, au passage, le nom d'un dossier/fichier > particulier).
Je sais ce que ça verrouille mais l'OP voulait empêcher le renommage du disque système pas des dossiers du premier niveau ;-)
Désolé de jouer les mouches du coche.... ;-)
Mais je viens d'essayer l'idée de Paul, si effectivement elle fonctionne dans une fenêtre du Finder pour les répertoires et fichiers "sous la racine", visiblement le Finder s'en moque pour les noms des icones de volumes qui apparaissent sur le bureau.
En mettant,
drwxr-xr-t 6 root admin 204B Dec 10 15:46 Volumes
pour le point de montage "standard" /Volumes, je peux renommer dans le Finder les noms des icones des volumes apparaissant sur le bureau. Je suis en Mac OS X 10.4.11.
Peut-être faut-il redémarrer, comme sous Windows ? ;-) (je n'ai pas essayé).
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela peut-être risqué. Des fichiers comme: lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym -r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym se créent à chaque démarrage.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
laurent.pertois
Jacques Perrocheau wrote:
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela peut-être risqué. Des fichiers comme: lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym -r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym se créent à chaque démarrage.
C'est root qui crée ces éléments, ça ne va pas l'arrêter.
Quant au nom du volume système, bah, c'est surtout esthétique, pour l'OS, ça reste /.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela
peut-être risqué. Des fichiers comme:
lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym
-r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym
se créent à chaque démarrage.
C'est root qui crée ces éléments, ça ne va pas l'arrêter.
Quant au nom du volume système, bah, c'est surtout esthétique, pour
l'OS, ça reste /.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Quant à le faire pour le volume de démarrage, j'ai l'impression que cela peut-être risqué. Des fichiers comme: lrwxr-xr-x 1 root admin 9B Nov 26 11:54 mach -> /mach.sym -r--r--r-- 1 root admin 590K Nov 26 11:54 mach.sym se créent à chaque démarrage.
C'est root qui crée ces éléments, ça ne va pas l'arrêter.
Quant au nom du volume système, bah, c'est surtout esthétique, pour l'OS, ça reste /.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Paul Gaborit wrote:
> Tu es sûr avec les ACLs ?
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le droit d'écriture pour tout le monde dans un dossier (gestion des droits Unix/Posix standard).
Logique, mais Nicolas proposait d'ajouter une ACE, justement.
Les ACL permettent évidemment une gestion beaucoup plus fine des droits.
Yep.
Mais, à ma connaissance, dans Mac OS X, il n'y a malheureusement pas d'interface graphique pour les configurer.
En partie, sans grande maîtrise, la section droits d'accès d'une fenêtre d'informations. Sinon, pas en standard, Sandbox :
<http://www.mikey-san.net/sandbox/>
Et sans GUI, il y a chmod.
> Pour rappel, elles fonctionnent ainsi avec les droits posix : > > effective access = (returned POSIX access) UNION (union of applicable > ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix et ACL moins les interdictions posées par les ACL.
Yep.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
> Tu es sûr avec les ACLs ?
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le
droit d'écriture pour tout le monde dans un dossier (gestion des
droits Unix/Posix standard).
Logique, mais Nicolas proposait d'ajouter une ACE, justement.
Les ACL permettent évidemment une gestion beaucoup plus fine des
droits.
Yep.
Mais, à ma connaissance, dans Mac OS X, il n'y a
malheureusement pas d'interface graphique pour les configurer.
En partie, sans grande maîtrise, la section droits d'accès d'une fenêtre
d'informations. Sinon, pas en standard, Sandbox :
<http://www.mikey-san.net/sandbox/>
Et sans GUI, il y a chmod.
> Pour rappel, elles fonctionnent ainsi avec les droits posix :
>
> effective access = (returned POSIX access) UNION (union of applicable
> ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix
et ACL moins les interdictions posées par les ACL.
Yep.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Non. Mon explication n'a de sens que *sans* ACL : on supprime juste le droit d'écriture pour tout le monde dans un dossier (gestion des droits Unix/Posix standard).
Logique, mais Nicolas proposait d'ajouter une ACE, justement.
Les ACL permettent évidemment une gestion beaucoup plus fine des droits.
Yep.
Mais, à ma connaissance, dans Mac OS X, il n'y a malheureusement pas d'interface graphique pour les configurer.
En partie, sans grande maîtrise, la section droits d'accès d'une fenêtre d'informations. Sinon, pas en standard, Sandbox :
<http://www.mikey-san.net/sandbox/>
Et sans GUI, il y a chmod.
> Pour rappel, elles fonctionnent ainsi avec les droits posix : > > effective access = (returned POSIX access) UNION (union of applicable > ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
Oui. En clair, les règles d'accès sont l'union des autorisations Unix et ACL moins les interdictions posées par les ACL.
Yep.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
xavier
Laurent Pertois wrote:
Quant au nom du volume système, bah, c'est surtout esthétique, pour l'OS, ça reste /.
Oh que non, pas pour Carbon, ni pour les saletés d'alias "traditionnels"
-- XAv Disponible au 1/9/2009 <http://www.xavierhumbert.net/perso/CV2.html>
Quant au nom du volume système, bah, c'est surtout esthétique, pour l'OS, ça reste /.
Oh que non, pas pour Carbon, ni pour les saletés d'alias "traditionnels"
-- XAv Disponible au 1/9/2009 <http://www.xavierhumbert.net/perso/CV2.html>
laurent.pertois
Xavier wrote:
Laurent Pertois wrote:
> Quant au nom du volume système, bah, c'est surtout esthétique, pour > l'OS, ça reste /.
Oh que non, pas pour Carbon, ni pour les saletés d'alias "traditionnels"
Juste.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
> Quant au nom du volume système, bah, c'est surtout esthétique, pour
> l'OS, ça reste /.
Oh que non, pas pour Carbon, ni pour les saletés d'alias "traditionnels"
Juste.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
> Quant au nom du volume système, bah, c'est surtout esthétique, pour > l'OS, ça reste /.
Oh que non, pas pour Carbon, ni pour les saletés d'alias "traditionnels"
Juste.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
