Pourquoi est-ce un problème de security d'avoir / usr / sbin possédé par bin?

Le Guide d'installation et d'utilisation de Sendmail (§1.3.1) affirme:

Pour des raisons de security, /, / usr et / usr / sbin doivent appartenir à root, mode 0755 2
[…]
2 Certains vendeurs les expédient en possession de bin; cela crée un trou de security qui n'est pas réellement lié à sendmail . […]

Pourquoi est-ce un trou de security? Existe-t-il des systèmes exécutant des process en tant que bin user?

    Si vous ne respectez pas les permissions «groupe» et «autre», quelque chose appartenant à root signifie que root seul a un contrôle total sur le file / directory.

    Quelque chose appartenant à un autre user signifie que l'user en plus de la racine a un contrôle total sur ce file. Maintenant, vous avez deux entités qui ont un contrôle total sur ce file / directory, alors que vous n'en aviez qu'un seul.

    Cela est particulièrement mauvais pour les exécutables placés dans les locations standard car d'autres users du système peuvent l'appeler et l'user propriétaire peut replace l'exécutable à sa volonté, en l'utilisant éventuellement pour des moyens malveillants. Espérons que sur ce système, l'user "bin" ne pourra pas se connecter de manière interactive via un shell null ou similaire dans /etc/passwd . Je parie que cela est fait pour permettre à un gestionnaire de packages de ne pas avoir à s'exécuter en tant que root. Cela en soi apporte probablement d'autres avantages.

    Cependant, si seul le directory / usr / sbin appartient à bin, et non aux exécutables à l'intérieur, alors ce n'est pas aussi mauvais.