Salut
jcezanna.
Je débarque tardivement dans ton fil (qui m'a donné de quoi retordre intellectuellement et, pour cette raison même, m'a captivé). Position d'épigone que j'affectionne - peut-être un peu commodément parce, tout enjeu de dépannage aboli (toi-même ayant trouvé une solution ici), aucune urgence n'exerce de pression sur l'esprit à qui il est loisible de spéculer. En contraste avec l'épure géométrique de tes messages, tu ne manqueras pas de juger l'allure de mes phrases bien rhétorique. Mais comme tu le notes à la fin :
En conclusion, même si mon problème est résolu, je reste sur ma faim n'ayant d'autre explication que celle d'un bug, ce qui me semble par trop facile.
☞ permets-moi de trouver l'invite belle pour apporter une petite contribution dans mon style propre de prose.
--------------------
Les commandes qu'on passe habituellement dans le «
Terminal» fonctionnent, parce que les objets logiques auxquels elles sont adressées ont une
existence intrinsèque (une "
haeccéité" auraient dit les
Scolastiques) : ce sont des "entités" discrètes considérables en soi (tel fichier, tel dossier), sur lesquelles une commande arrive à s'
arrêter, à cause de ce statut "intransitif".
Or, tout en étant des
objets logiques assimilables à d'autres objets logiques (des
fichiers associés à des
droits), les
liens symboliques en diffèrent, en ce qu'ils n'ont pas une
valeur existentielle indépendante, mais
relative à l'existence d'autres objets (leur domaine de référence) par rapport auxquels ils valent en tant que pointeurs. En cela, ils sont des
objets logiques transitifs (
transitionnels).
J'en tire, spéculativement parlant, la conséquence suivante : aussi longtemps qu'on laisse à un
lien symbolique son statut d'objet
transitif, les commandes qui l'impliquent ne vont pas "porter" sur lui, parce que ce n'est pas un objet discret capable de les "
arrêter", mais vont le
traverser littéralement sans l'affecter. Je ne parle pas simplement de commandes comportant explicitement une option récursive
-R impliquant de
suivre la direction du
lien symbolique, pour s'adresser à la sous-arborescence de fichiers située juste "en-dessous" ; je parle de commandes classiques adressées non-récursivement à un objet logique, et censées
s'arrêter à l'existence de cet objet. Eh bien ! il y a tout lieu de penser qu'un
lien symbolique n'ayant pas justement une valeur d'existence indépendante, aucune commande classique à destination d'objets discrets sur lesquels elles peuvent
s'arrêter n'arrivera, justement, à
s'arrêter lorsqu'on lui donne pour cible un
lien symbolique. Elle le
traversera comme s'il était "incorporel", sans y trouver la "résistance" d'une entité logique discrète lui permettant de produire ses effets. Je ne dis pas qu'elle le
traversera vers le domaine que le
lien symbolique pointe (procédé inopérant en l'absence d'une option récursive
-R qui l'impliquerait) ; je dis qu'elle le
traversera tel quel, parce que le lien n'est pas intrinsèquement une "entité" capable d'
arrêter la commande sur une existence indépendante qui serait la sienne.
Cette considération rhétorique (pour ne pas dire philosophique) m'amène à la conjecture suivante ; prenons les 3 commandes classiques de manipulation des droits des objets logiques :
chown (
accédants),
chmod (
permissions) &
chflags (
flags). Eh bien ! Aucune de ces commandes, ciblée sur un
lien symbolique, ne doit avoir le moindre
effet, aussi longtemps que lien est laissé dans son état natif d'objet
transitif --> elles doivent le
traverser, sans qu'un message d'erreur ne soit retourné, mais sans non plus pouvoir
s'arrêter sur lui afin de modifier ses propriétés. Elles doivent "porter à vide".
--------------------
J'ai appliqué cette spéculation en me créant sur le Bureau un
lien symbolique : init d'un dossier
brol. Le lien
init se crée, associé aux droits :
755 macomaniac staff. Si j'enchaîne à présent sur lui les commandes (en droits
root) :
Bloc de code:
chown 0:0 Desktop/init
chmod 644 Desktop/init
chmod +a "everyone deny write,delete,append,writeattr,writeextattr,chown" Desktop/init
chflags uchg Desktop/init
et si j'enchaîne par la commande :
afin de vérifier l'état des permissions
POSIX +
ACL +
flags, alors j'obtiens en résultante :
exactement comme au point de départ. Ma conjecture spéculative est donc vérifiée par là : le
lien symbolique a été chaque fois
traversé par les commandes successives, sans mention d'erreur, mais sans "résistance d'objet" de sa part qui aurait permis d'
arrêter sur lui les commandes de manière à modifier la donne. Il y a eu action "à vide".
Or, je remarque que dans les options de ces 3 commandes :
chown,
chmod &
chflags, est disponible une option
-h qui est exclusivement réservée aux
liens symboliques et à aucun autre objet logique. Voici comment elle est documentée :
Bloc de code:
chown -h : If the file is a symbolic link, change the user ID and/or the group ID of the link itself.
chmod -h : If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.
chflags -h : If the file is a symbolic link, change the file flags of the link itself rather than the file to which it points.
--> voici comment j'interprète : l'option
-h permet d'
arrêter chacune de ces commandes sur le
lien symbolique qui, sinon, ne les
arrêterait pas, càd. traite le
lien symbolique comme si c'était un objet ordinaire : une "entité logique discrète", ayant une valeur existentielle indépendante (une "
haeccéité"). Si donc à présent je modifie ainsi mon jeu de commandes :
Bloc de code:
chown -h 0:0 Desktop/init
chmod -h 644 Desktop/init
chmod -h +a "everyone deny write,delete,append,writeattr,writeextattr,chown" Desktop/init
chflags -h uchg Desktop/init
alors la commande enchaînée :
donne le retour :
Bloc de code:
lrw-r--r--+ 1 root wheel uchg 52 28 jui 06:37 Desktop/init -> /Users/macomaniac/Desktop/brol
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
ce qui confirme que les propriétés du lien ont bien été manipulées comme s'il s'était agi d'un fichier ordinaire.
--------------------
Remarques addtionnelles :
- a) il est clair que les options
-h et
-R sont logiquement
contradictoires et ne sont pas supportées ensemble, puisque
-h consiste à traiter le lien comme un
terminus ad quem sur lequel arrêter la commande, alors que
-R consiste à
traverser le lien pour s'arrêter sur le domaine qu'il pointe (il est à noter que l'option récursive
-R ne fonctionne pas pareil avec un
lien symbolique et un dossier : lorsque la cible est un dossier, l'option
-R impacte à la fois l'objet immédiat = le dossier, et l'arborescence en-dessous de lui = son contenu ; lorsque la cible est un
lien symbolique, l'option
-R n'impacte que l'objet pointé = l'arborescence du domaine, et absolument pas le lien lui-même, parce que, comme je l'ai philosophiquement expliqué, il n'est pas intrinsèquement une "entité" capable d'
arrêter sur lui-même une commande, par défaut d'
existence discrète).
- b) L'option
-N de la commande
chmod est évidemment inopérante, telle quelle, pour un
lien symbolique pour la raison précédemment exposée : le lien est
traversé par la commande sans qu'elle
s'arrête sur lui pour manipuler ses propriétés d'objet. Cette option marche-t-elle alors en association avec l'option
-h qui fixe le lien à un statut de
terminus ad quem ? Eh bien ! pas davantage. L'option
-N consiste à vider l'
ACL (liste de méta-permissions) associée à un objet de ses entrées appendues chacune à un accédant (
ACE). Il paraît bien que c'est trop demander à la fonction
-h d'arrêt sur le lien comme s'il était une "entité" terminale. Afin de vider l'
ACL associée à un
lien symbolique de ses entrées éventuelles, il faut itérer autant de commandes de destruction qu'il y a d'entrées
ACE en utilisant le type de syntaxe que tu avais utilisée (mais l'absence d'option
-h dans ta commande l'avait fait passer
à travers le lien sans agir) --> exemple pour l'unique
ACE de l'
ACL de mon fichier
init :
qui vide l'
ACL de son entrée relative à
everyone dont le rang d'
ACE est
0.
- c) Qu'un
lien symbolique se retrouve
verrouillé par l'
attribut d'utilisateur immuable (le
flag:uchg), cela se conçoit par exemple suite à une action graphique de l'utilisateur dans une fenêtre d'information du
Finder (cocher la case : "
Verrouillé"). On notera que cette action graphique équivaut strictement à la commande (sur mon exemple où l'objet est un
lien symbolique) :
Bloc de code:
chflags -h uchg Desktop/init
Cet
attribut d'utilisateur immuable l'emportant sur toute espèce de droits directs, y compris de la part de
root,
verrouille littéralement un objet tant dans son existence que dans tout acte d'écriture le concernant. Il convient donc de le faire sauter en préalable par une commande de type :
Bloc de code:
chflags -h nouchg Desktop/init
avant toute action sur l'
ACL ou encore avant une commande de destruction
rm.
--------------------
Je ne pense pas avoir "fait le tour" du problème (si riche en implications de toutes sortes) que tu as soumis dans ce fil.
Personnellement, je ne crois nullement que la présence, dans l'
ACL d'un objet logique, de
restrictions (du style :
"everyone deny delete") puisse impacter la possibilité au sommet (au niveau
root) d'exercer la
permission qui se trouve déniée à la base (au niveau
everyone) : ici
rm. Mes expérimentations m'ont montré que, si
"everyone deny delete", alors dans le triplet des droits
POSIX l'
user et le
group, par ricochet, se trouve privés de la capacité d'exercer la même
permission de manière
automatique (à l'exception de
root, s'il est cet
user). Mais ceux des accédants qui peuvent passer en droits
root via une authentification par mot-de-passe
admin, outrepassent (
override) cette limitation et peuvent exécuter la
permission en s'assimilant à l'exception
root(voir mon argumentation sur ce cas de figure ici - message
#12 ☞
problème de permissions☜).
Je ne me figure pas, dans ton cas, que la présence d'une
ACE :
"everyone deny delete" dans l'
ACL de ton
lien symbolique ait pu bloquer une commande
rm en droits
root. Je conjecturerais bien un
flag:uchg qu'il aurait fallu faire sauter par une commande (
root) :
Bloc de code:
chflags -h nouchg /path/Current
- mais ce qui contrarie cette conjecture est le retour de commande que tu avais obtenu inauguralement :
Bloc de code:
ls -ale@O
lrwxr-xr-x+ 1 root wheel - 1 3 nov 2012 Current -> A
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
--> s'il y avait eu un
attribut d'utilisateur immuable, alors le
flag:uchg aurait été mentionné entre les accédants
root wheel et la date
3 nov 2012 - ce qui n'était pas le cas.
☞ J'ai peur d'avoir échoué à rendre une raison suffisante de ton blocage dans la gestion du lien symbolique : Current.
--------------------
