Pourquoi changer le propriétaire d'un lien symbolique sous Linux?

12

Sous Linux, il est possible de changer le propriétaire ou le propriétaire du groupe d'un lien symbolique (lien symbolique). Je me demandais pourquoi quelqu'un voudrait faire cela, car les autorisations d'un lien symbolique ne sont pas utilisées lors de l'accès à un fichier via celui-ci.

Je ne peux imaginer qu'un seul cas d'utilisation où cela pourrait être utile: pour permettre à un utilisateur de supprimer un lien symbolique dans un répertoire avec du bit collant.

Connaissez-vous d'autres cas où il pourrait être utile de changer le propriétaire ou le propriétaire du groupe d'un lien symbolique?

symlink

— user368507
source

6

Supposons que root travaille dans un répertoire dans lequel Eve peut écrire. Il y a un fichier foodans ce répertoire qui doit être changé pour appartenir à Eve. Donc, les types de racine chown eve foo. Mais juste avant que root ne touche Enter, Eve s'exécute ln -sf /etc/passwd foo. /etc/passwdAppartient maintenant à Eve! Si root peut s'exécuter chown -h eve foopour s'assurer de ne pas suivre les liens symboliques, alors le plus de mal qui peut être fait est qu'un autre fichier dans le même répertoire a été modifié pour appartenir à Eve.

lchownest également pratique lorsque vous changez le propriétaire d'une arborescence de répertoires. Vous n'avez pas à vous soucier de toucher accidentellement un fichier en dehors de l'arborescence car vous avez appelé chownun lien symbolique.

— Gilles 'SO- arrête d'être méchant'
source

"Si root peut exécuter chown -h bob foo pour s'assurer de ne pas suivre les liens symboliques, alors le plus de mal qui puisse être fait est qu'un autre fichier du même répertoire a été changé pour appartenir à Eve.". Je suppose que vous voulez dire "chown -h eve foo". L'autre fichier qui pourrait être modifié, c'est le lien symbolique ai-je raison?

— user368507

@ user5528 L'autre fichier n'est peut-être pas un lien symbolique: Eve peut toujours s'exécuter mv myfile fooet root finira par changer le propriétaire de myfile. Mais myfiledoit être un fichier qu'Eve peut créer ou déplacer dans ce répertoire, il ne doit pas s'agir d'un fichier du système.

— Gilles 'SO- arrête d'être méchant'

2

Bien qu'intéressant et manifestement approuvé par le demandeur, je ne vois pas comment cette réponse répond à la question. Cela semble plus expliquer pourquoi on pourrait utiliser chown -hcomme mesure de prudence lors du changement de propriété d'un fichier qui n'est pas censé être un lien symbolique, mais qui pourrait quand même l'être (cas de bord, IMO). Cela n'explique pas pourquoi on pourrait souhaiter changer la propriété d'un fichier qui est en fait destiné à être un lien symbolique, ce qui est la question posée.

— Ivan X

Pourquoi chownchanger le propriétaire d'un "fichier en dehors de l'arborescence" est tout ce que vous changez est le propriétaire du répertoire?

— Melab

@Melab Lorsque vous changez le propriétaire d'une arborescence de répertoires , c'est-à-dire la suppression de l'utilitaire chown -R, qui appelle l' (l)chownappel système à chaque entrée de répertoire. Si l'entrée de répertoire est un lien symbolique, vous ne devez pas appeler l'appel chownsystème dessus car cela affecterait la cible du lien qui peut être situé en dehors de l'arborescence.

— Gilles 'SO- arrête d'être méchant'

8

Apache peut être configuré pour suivre les liens symboliques uniquement si le propriétaire du lien correspond au propriétaire de la destination. Cela peut aider à empêcher les utilisateurs de créer des liens pour accéder au Web à des fichiers qu'ils ne possèdent pas (par exemple / etc / passwd).

... alors disons que, en tant que root, vous vouliez qu'Apache suive un lien pour afficher un certain fichier journal, qui appartenait à Xymon ou quelque chose, mais vous ne vouliez pas assouplir la sécurité d'Apache en lui permettant de suivre les liens symboliques quel que soit le propriétaire . Ensuite, vous voudrez peut-être faire de xymon le propriétaire du lien symbolique.

— Lars Rohrbach
source

1

D'accord. Je sais que ce n'est pas lié, mais quel est l'intérêt de ce comportement dans Apache? Je veux dire si l'utilisateur est capable de lire le fichier, pourquoi se donner la peine de le lire à partir de l'accès Web? thx

— user368507

Eh bien, ce n'est pas seulement un utilisateur local qui lit le fichier; si apache peut le lire, alors potentiellement tout le monde peut le lire. Et si une vulnérabilité d'Apache permettait la création d'un lien symbolique vers /etc/passwd, le badguy pourrait avoir un accès en lecture à ce fichier sans avoir d'autre accès local - mais serait contrecarré par le lien symbolique appartenant à Apache.

— Lars Rohrbach

4

La première réponse ne semble pas répondre à la question, et la seconde ne s'applique qu'à Apache.

Une chose à laquelle je peux penser pour linux en général est qu'il n'est possible pour un utilisateur ordinaire de créer un lien dur vers un lien symbolique que si l'utilisateur est le propriétaire du lien symbolique. Pourquoi on voudrait faire un tel lien, je ne sais pas.

Une autre chose est qu'un utilisateur ordinaire ne peut changer la propriété de groupe d'un fichier que si l'utilisateur est propriétaire du fichier (et est également membre du groupe auquel le fichier est ajouté.) Cela soulève la question de savoir à quoi appartient la propriété de groupe de un lien symbolique le fait. Dans une organisation, il peut être utile comme balise pour indiquer quelle équipe aurait besoin du lien.

De plus, sur Ubuntu au moins, n'importe qui peut mettre à jour l'horodatage d'un lien symbolique. Cependant, certains systèmes peuvent uniquement autoriser le propriétaire à le faire. À quoi sert l'horodatage pour un lien symbolique, je ne suis pas sûr, mais il peut donner des informations utiles sur son utilisation.

Edit: Je viens de réaliser une autre raison pour laquelle la propriété serait importante. Le lien peut se trouver à l'intérieur d'un répertoire collant, où seul le propriétaire d'un fichier peut le supprimer ou le renommer.

— un autre type
source

0

J'ai un programme qui s'ajoute à un fichier journal. Ces fichiers journaux sont créés chaque mois avec un nom différent. Plutôt que de demander au logiciel de trouver le nom de fichier exact, j'utilise un nom de fichier "générique" (par exemple data.log) qui est un lien symbolique qui pointe vers le fichier en cours pour ce mois. Ceci est automatisé sur une tâche cron.

Maintenant qu'un nouveau fichier mensuel est créé, il doit pointer le lien symbolique vers le nouveau fichier. En cas de conflit de propriété / groupe, le logiciel ne peut pas modifier le lien symbolique. Vous avez donc besoin de privilèges d'écriture de propriété / groupe pour modifier le lien symbolique.

— user173610
source

0

Si vous voulez avoir un lien vers un fichier sur votre écran d'ouverture, le lien symbolique doit être dans le

"/ home / nom d'utilisateur / bureau"

annuaire.

Et, le lien symbolique lui-même doit avoir la propriété root: root (0: 0), sinon le lien ne fonctionne pas.

(Ubuntu / Debian etc.)

— Helen Craigman
source