Modifier les autorisations pour un lien symbolique

37

J'ai un lien symbolique avec ces autorisations:

lrwxrwxrwx 1 myuser myuser       38 Aug 18 00:36 npm -> ../lib/node_modules/npm/bin/npm-cli.js*

Le lien symbolique se trouve dans une archive .tar.gz. Maintenant, lorsque je décompresse l'archive tar.gz en utilisant maven, le lien symbolique n'est plus valide. J'essaie donc de reconstruire le lien symbolique. Je crée d'abord le lien symbolique à l'aide de ln, mais comment puis-je définir les mêmes autorisations que le lien symbolique d'origine?

symlink chmod

— u123
source

59

Vous pouvez créer un nouveau lien symbolique et le déplacer à l'emplacement de l'ancien lien.

ln -s <new_location> npm2
mv -f npm2 npm

Cela préservera la propriété du lien. Vous pouvez également utiliser chownpour définir manuellement la propriété du lien.

chown -h myuser:myuser npm

Sur la plupart des systèmes, les autorisations des liens symboliques importent peu. Lors de l'utilisation du lien symbolique, les autorisations des composants de la cible du lien symbolique seront vérifiées. Cependant, sur certains systèmes, ils sont importants. MacOS requiert une autorisation de lecture sur le lien pour readlink, et l' sympermoption de montage de NetBSD force les vérifications des autorisations de lien sur la lecture et la traversée. Sur ces systèmes (et leurs proches, y compris FreeBSD et OpenBSD), il existe une -hoption équivalente à chmod.

chmod -h 777 npm

— JdeBP
source

1

Je viens de rencontrer un problème de permission avec des liens symboliques sur un serveur CentOS 6.8. Les liens symboliques avaient propriétaire: groupe de racine: racine. Lorsque le propriétaire et le groupe ont été modifiés pour devenir l'utilisateur propriétaire du répertoire dans lequel ils se trouvaient, comme indiqué dans cette réponse, le problème d'autorisation a disparu.

— Night Owl

Juste pour fournir une clarification. Pour changer la propriété ou les droits sur un lien symbolique, l'indicateur -h affectera le fichier de lien symbolique au lieu du fichier déréférencé.

— UltimaWeapon

12

Lorsque vous essayez d'utiliser chmodpour définir les autorisations du lien, vous devez définir les autorisations de la cible du lien. Les autorisations du lien n'ont pas de sens.

— Simplement fais-le
source

2

Et si quelqu'un change le lien en un code malveillant? Le code original peut même être quelque chose auquel root ne peut accéder. Par exemple, dans les scripts crontap.

— Aliqandil

@aliqandil Généralement, un utilisateur peut supprimer et recréer tout fichier d'un répertoire pour lequel il dispose d'un accès en écriture. Sous bash, pour un fichier testavec -rw-rw-r-- root root, car rm testje reçois l'invite rm: remove write-protected regular empty file 'test'?La solution consiste à placer les fichiers sensibles dans des répertoires auxquels les utilisateurs ont un accès en lecture seule.

— AnOccasionalCashew le

5

Quand vous avez un lien comme:

link -> foo/bar

et voulez le changer pour:

link -> new/target

Il y a deux cas à considérer:

foo/barn’est pas un répertoire ou n’existe pas ou vous n’avez pas accès à la recherche foo. ensuite
```
ln -s new/target link
```
échouera car linkexiste déjà, mais vous pouvez y remédier en utilisant le standard:
```
ln -fs new/target link
```
foo/barest un répertoire (et vous avez le droit de recherche foopour pouvoir déterminer s’il foo/bars’agit d’un répertoire). Dans ce cas, quand vous faites:
```
ln -s new/target link
```
ou
```
ln -fs new/target link
```
Cela s'entend comme la création d'un nouveau targetlien symbolique dans le linkrépertoire (il links'agit d'un répertoire car il s'agit d'un lien symbolique vers le foo/barrépertoire). Donc, vous allez créer un:
```
foo/bar/target -> new/target
```
Pour surmonter cela, GNU lna une -Toption pour que le nom du lien soit toujours considéré comme un nom de lien, et non comme un répertoire dans lequel créer le ou les liens. Donc, avec GNU ln:
```
ln -fsT new/target link
```
marchera. Comme auparavant, il supprimera le linklien symbolique d' origine et le créera à nouveau avec new/targetpour cible (et le processus 'euid et egid en tant que propriétaire).

GNU a lnaussi une -noption. Cela fonctionne de la manière suivante -Tsauf que linkest en fait un répertoire réel, auquel cas le lien symbolique sera toujours créé à l'intérieur de ce répertoire (au lieu d'échouer avec une erreur).

De manière portable, votre meilleure option consiste à supprimer le lien en premier lieu, puis à le recréer:
```
rm -f link && ln -s new/target link
```

Sur la plupart des systèmes, les autorisations sur les liens symboliques sont ignorées et généralement corrigées rwxrwxrwx.

Sur les systèmes où les autorisations de lien symbolique importent (comme OS / X où vous avez besoin d'une autorisation de lecture sur un lien symbolique pour pouvoir résoudre sa cible), il existe généralement un moyen de les modifier ( chmod -hsous OS / X).

La propriété, bien que comme ci-dessus ne soit pas pertinente pour l'accès au fichier désigné par le lien symbolique sur la plupart des systèmes, peut avoir une autre pertinence par rapport au tbit du répertoire parent ou aux quotas ... ) et il existe une commande standard pour le changer:

chown -h user[:group] the-link
chgrp -h group the-link

— Stéphane Chazelas
source

0

Si vous avez vraiment besoin de changer la permission des liens symboliques (généralement sans signification, comme écrit dans d'autres réponses), j'ai réussi à utiliser l' -Roption de chown:

chown -R myuser:mygroup link

Si -Rn'a pas été utilisé, les autorisations n'ont pas été modifiées.

— Miroslav Mocek
source

Cela fonctionnera avec GNU chowncar -Rcela -Py est implicite , mais ce n’est pas garanti et cela ne fonctionnera pas dans d’autres implémentations gommées. Le moyen standard pour changer la propriété des liens symboliques est avec l' -hoption. Je viens de mettre à jour la réponse acceptée qui était incorrecte.

— Stéphane Chazelas