web-dev-qa-db-fra.com

Comment puis-je configurer un mot de passe pour la commande 'rm'?

Mes amis continuent à supprimer mes fichiers en utilisant le terminal. Alors, aidez-moi en expliquant comment créer un mot de passe pour la commande rm.

command-linepermissionspasswordrm
29
aswin

Il n’existe pas de moyen simple de configurer un tel mot de passe sur la commande rmelle-même, non sans une grande quantité de piratage de code qui va probablement casser des choses telles que apt-get qui installe des packages, supprime des fichiers et vous oblige à entrer le mot de passe mille fois, ou potentiellement perturber l'accès à la commande aux personnes qui en auraient besoin (comme vous, pour supprimer vos propres fichiers). Pour ce faire, vous pouvez avoir plusieurs comptes d'utilisateur et plusieurs ensembles d'autorisations d'accès, ainsi que limiter l'accès à différentes sections de données, telles que votre répertoire de base, afin qu'elles ne puissent pas y accéder.

(L’autre option est constituée de comptes d’utilisateur individuels pour chaque utilisateur, puis de listes de contrôle d’accès, comme détaillé dans le autre réponse qui a été publié par Videonauth )

Voici le problème principal: vous laissez vos amis utiliser votre système. Cela a de nombreuses implications pour la sécurité - le concept de "toute personne ayant un accès physique à la boîte va être capable de contrôler le système et d’accomplir toutes les tâches "est un mantra de sécurité informatique, c’est pourquoi vous ne" partagez "pas l’accès aux systèmes physiques, sauf avec du personnel autorisé de confiance.

Le seul moyen vraiment sain de le faire est de ne pas donner à vos amis l'accès à votre ordinateur et de leur attribuer un "dédié". "Système" invité qu'ils peuvent utiliser, que vous ne vous souciez pas autant des fichiers. C'est le moyen le plus "sécurisé" de protéger vos fichiers.

Bien sûr, si ce n'est pas une option, alors votre seule option vraiment sûre est de configurer plusieurs comptes utilisateur, un pour chaque utilisateur, avec des dossiers personnels différents, et de ne leur permettre pas d'accéder à votre propre répertoire personnel ou à celui de tout autre utilisateur. des répertoires. Et ensuite, gardez tout ce que vous ne voulez pas qu'ils touchent dans votre répertoire personnel, et ne leur donnez pas d'accès Sudoname__, le mot de passe rootou ne leur partagez pas votre mot de passe.

Voici comment vous feriez ceci:

Disons que je m'appelle "Foo" et que je veux que l'utilisateur "Bar", un ami, utilise mon système mais n'accède pas à mes fichiers. La première étape consiste à interdire l'accès à mon répertoire personnel à tout le monde, à l'exception de moi. Ceci permet aux autres utilisateurs de ne pas supprimer vos fichiers, mais également d'empêcher les autres utilisateurs de fouiller dans votre répertoire personnel et de voir quels types de fichiers vous avez chez vous. annuaire:

chmod 750 /home/Foo

La deuxième étape consiste à créer un compte utilisateur pour "Bar" (ne saisissez PAS le texte entre parenthèses ci-dessous, il s'agit uniquement d'informations). De cette façon, nous pouvons nous assurer qu'il dispose de son propre ensemble de droits d'accès:

Sudo adduser --create-home --user-group --Shell /bin/bash Bar
Sudo passwd Bar
(set a temporary password - you will not see characters as you type though)

La troisième étape consiste à restreindre ensuite leur répertoire personnel afin que personne ne puisse extraire leurs fichiers non plus. Cela ne fait que rendre les choses égales.

Sudo chmod 750 /home/Bar

Lavez-vous les mains, rincez-les bien, puis répétez ces étapes, quel que soit le nombre d'utilisateurs de votre système. Ils ne pourront pas accéder à vos fichiers, et comme vous n'allez pas leur donner de privilèges d'administrateur, ils ne peuvent pas supprimer vos fichiers sans tenter de Sudode le faire. Comme vous ne le permettez pas, ils 'peuvent Touche pas tes affaires. Et ils ne pourront pas non plus voir vos fichiers, sans devenir super-utilisateur, ce qui ne se produira pas ici.

N'OUBLIEZ PAS QUE: En donnant à quelqu'un un accès physique à la machine, ou un accès en général, vous êtes va mettre vos fichiers et vos données en danger. C’est un fait largement accepté dans le monde de la sécurité informatique, et qui reste toujours valable. Donner à vos amis l'accès à votre ordinateur mettra toujours vos données en péril. Vous pouvez donc leur donner leur propre système, ou tout simplement ne leur donnez pas accès à votre machine. .

Juste une note sur le chiffrement du disque

Bien que le chiffrement de disque fonctionne bien pour protéger vos données d'un tiers, il existe des limites.

  1. Si le système est allumé, le disque est déjà déchiffré, vous êtes donc à risque.
  2. Certains systèmes ont des approches de chiffrement de disque cassées . Par exemple, certains systèmes Acer utilisent votre mot de passe pour autoriser uniquement le cryptage/décryptage et utilisent des mots de passe codés en dur, ou utilisez un cryptage faible facilement déchiffrable.
  3. Il existe toujours des méthodes permettant d'intervenir dans les "clés" ou d'essayer de les extraire de la mémoire juste après la mise hors tension d'un système, mais avant que les données RAM ne soient "perdues" ou détériorées. (Je n'entrerai pas dans les détails, mais ces risques existent ).
  4. L'accès physique à la machine, que le système soit crypté ou non, mettra toujours vos données en péril. Ne donnez pas d'accès physique (ou d'accès réseau distant) aux personnes à qui vous ne voulez pas donner potentiellement un accès complet à votre système.

Bien que Disk Encryption ne résolve pas ces problèmes, il crée des problèmes supplémentaires pour un acteur menaçant. Quelqu'un qui est un méchant peut abandonner s’il est crypté, ou bien il peut vous torturer (file d’attente obligatoire bande dessinée XKCD Security ).

Par conséquent, si votre système est crypté, mais que vous laissez les autres utilisateurs l’utiliser, ils ont soit un mot de passe à décrypter, soit vous laissez votre ordinateur portable décrypté pour pouvoir entrer en SSH ou avoir un accès physique. Dans les deux cas, c'est mauvais.

Cela dit, si votre système n’est pas chiffré, cette section n’a aucune pertinence pour vous.

46
Thomas Ward

Cela ne concerne peut-être pas vraiment la commande rm, car il existe des moyens simples de supprimer des fichiers sans l’utiliser . Si le problème vient de ce que vos amis abusent de la commande rm par inadvertance, des solutions limitant son utilisation ou la faisant fonctionner différemment peuvent être utiles. En revanche, si le problème est que vos amis traitent délibérément vos données comme vous ne le souhaitez pas, , vous devez alors mettre en œuvre les mesures de sécurité réelles , et aucune solution ne se concentre sur le rm. La commande elle-même (ou tout ensemble de commandes discret) vous gardera en sécurité.

Avez-vous besoin de contrôler l'accès, ou simplement d'éviter les erreurs honnêtes?

En supposant que vos amis sachent que vous ne souhaitez pas qu'ils suppriment vos fichiers, il existe deux possibilités:

  1. Ils pourraient le faire exprès. Dans ce scénario, vos amis suppriment délibérément vos fichiers et vous ne pouvez même pas leur faire confiance pour essayer de respecter vos souhaits quant à la manière dont ils traitent vos données lorsqu'ils utilisent votre ordinateur. La seule solution à ce problème est d'utiliser une mesure de sécurité réelle et effective , comme l'explique Thomas Ward en détail . Souvent, la meilleure mesure consiste à les empêcher d’utiliser votre ordinateur. Mais leur faire utiliser leurs propres comptes d'utilisateurs peut offrir une certaine protection.

  2. Ils pourraient le faire par erreur. Dans ce scénario, vos amis sont extrêmement exposés aux accidents et ils continuent à exécuter des commandes rm qu'ils souhaiteraient ne pas avoir. Ils veulent vous traiter, vous et vos données, avec respect, mais en pratique, ils ne savent pas trop le faire, car ils continuent d'exécuter la mauvaise commande et de supprimer le mauvais fichier ... ou quelque chose du genre. Même s'il serait bien de croire que c'est ce qui se passe, je vous déconseille de supposer que les personnes qui continuent de supprimer vos données après leur avoir demandé de cesser de fonctionner fonctionnent sans mauvaise volonté.

    De plus, même si leurs intentions sont bonnes, leur donner des comptes d’utilisateurs séparés reste le moyen le plus sûr de les empêcher de supprimer vos fichiers, en plus de ne pas leur permettre d’utiliser votre ordinateur.

Si la situation est vraiment # 2 - vos amis n'essayent pas de supprimer vos fichiers, mais ont simplement besoin d'aide (pas de les effacer accidentellement , et le seul Ils les suppriment accidentellement par l'utilisation abusive par inadvertance d'un petit nombre de commandes (comme rm) qu'ils ont des difficultés à utiliser correctement - alors les techniques de answer de Videonauth peuvent être utiles . Mais vous devez comprendre qu’il ne s’agit pas de mesures de sécurité, car la commande rm n’est qu’un des moyens nombreux de supprimer des fichiers . Voir ci-dessous pour plus de détails.

Je vous recommande de vous demander: "Ma situation est-elle fondamentalement la même que si, plutôt que les autres personnes utilisant mon ordinateur, celui qui utilisait rm de manière incorrecte?"

Si la réponse est non , il s'agit d'une question de sécurité des informations et vous devez empêcher vos amis d'utiliser votre compte utilisateur. Si la réponse est oui , vous pouvez utiliser les mêmes approches que si vous étiez celui qui utilisait mal rm:

  • Education. Vos amis ont besoin de savoir ce qu’ils font et comment l’éviter.
  • Modifications de l'interface. Sans supprimer la possibilité réelle de supprimer des fichiers (ce qui nécessite des comptes utilisateur distincts), vous pouvez rendre plus difficile la suppression accidentelle de fichiers en: faire en sorte que l'exécution de rm file par lui-même, sans autre action, ne supprime pas immédiatement file. La réponse de Videonauth donne une approche à ce problème. Dans cette réponse, j'en présente un autre.

Mais même si vos amis n'essayent pas de faire quelque chose de mal, vous devriez toujours envisager de leur demander d'utiliser leur propre compte d'utilisateur distinct . Cela résoudra tout de même le problème: les mêmes mesures de sécurité qui protègent les données contre une destruction délibérée le protègeront également de la destruction involontaire. Même sans intention malveillante, si quelqu'un continue à faire quelque chose que vous ne voulez pas qu'ils fassent, vous ne pouvez pas lui faire confiance pour s'abstenir de le faire.

Faire rm une invite avant la suppression peut aider à éviter certaines erreurs.

Pour aider les gens à éviter accidentellement la suppression de fichiers avec rm, vous pouvez créer rm un Shell alias qui exécute réellement rm -i. Le passage de l'indicateur -i à rm provoque l'invite avant la suppression de chaque fichier (voir man rm ).

Vous pouvez le faire (pour votre compte d'utilisateur) en ajoutant alias rm='rm -i' à votre fichier .bash_aliases ou .bashrc. Voir cette question et celui-là pour plus de détails. Cela prendra effet pour vos coquilles bash nouvellement ouvertes.

Ceci ne fournit aucune sécurité réelle et ne permet pas non plus d'éviter les erreurs, car:

  • Ils peuvent choisir de procéder à la suppression lorsque vous y êtes invité.
  • Ils peuvent contourner l'alias de nombreuses manières, notamment en exécutant /bin/rm ou en le désalignant (unalias rm).
  • Il existe de nombreuses situations où le développement d'alias ne se produit pas , et dans ces situations, rm ne sera pas exécuté avec -i.
  • Ils peuvent toujours supprimer des fichiers en utilisant l’une des techniques qui ne nécessitent pas rm (comme c’est le cas avec l’approche de Videonauth - voir ci-dessous).
  • Ils peuvent toujours endommager les données sans supprimer aucun fichier, par exemple en les écrasant ou en modifiant autrement leur contenu (comme c'est également le cas avec l'approche de Videonauth).

Mais si vous n'avez pas besoin de sécurité réelle (voir ci-dessus), c'est peut-être la voie à suivre. Par rapport à l'approche consistant à empêcher vos amis d'utiliser la commande rm fournie par le système:

  • L'aliasing rm à rm -i est moins efficace pour éviter les erreurs - jusqu'à ce qu'ils utilisent une autre technique pour supprimer des fichiers. À ce stade, les empêcher d’utiliser rm sera totalement inefficace, même s’ils n’essayent pas de faire quelque chose de mal, car ils utiliseront probablement unlink (ou l’une des nombreuses autres commandes qui supprime un fichier) avec une égale irréflexion.

  • D'autre part, comme l'expansion des alias ne se produit que dans certaines situations - en gros, une utilisation interactive classique de Shell - vos amis peuvent penser qu'ils vont être invités à le faire lorsqu'ils ne le sont pas vraiment (car la commande est en mode un script, par exemple, ou issu d'un shell différent). Le comportement de Videonauth n'a pas ce problème, ce qui est un avantage objectif de cette méthode par rapport à alias rm='rm -i'.

  • Lorsqu'un script est exécuté, à moins qu'il soit écrit délibérément pour utiliser des alias, vos alias ne sont pas développés. Cela signifie qu'il est très peu probable que l'aliasing rm à rm -i casse. Ceci est un avantage objectif de alias rm='rm -i'.

rm ne peut rien faire, aucun programme parfaitement ordinaire ne pourrait le faire.

Il n'y a vraiment rien de spécial à propos de rm. Il s'agit d'un moyen pratique et auto-documenté de supprimer des fichiers. Limiter son accès risquerait donc de compromettre de nombreux scripts qui en dépendent. Mais c’est loin d’être le seul moyen de supprimer des fichiers - c’est un programme ordinaire.

Quelques commandes exécutent certaines tâches qu'un utilisateur limité (autre que root ) ne peut pas exécuter sans les exécuter. Par exemple, Sudo vous permet d'exécuter des programmes en tant qu'utilisateur différent, après vous être assuré que vous y êtes autorisé. passwd édite la base de données où sont stockés les mots de passe des utilisateurs, mais vous permet uniquement de modifier votre propre mot de passe (sauf si vous êtes root, auquel cas vous pouvez modifier le mot de passe de quiconque).

/usr/bin/Sudo et /usr/bin/passwd peuvent le faire car ils ont le bit setuid set, comme indiqué par le s qui apparaît dans la colonne la plus à gauche lorsque vous exécutez ls -l:

ek@Io:~$ type -a Sudo passwd rm
Sudo is /usr/bin/Sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/Sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root  60272 Feb 18  2016 /bin/rm
-rwsr-xr-x 1 root root  54256 Mar 29  2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/Sudo

Notez que /bin/rm n'a pas s: ses autorisations sont -rwxr-xr-x, alors que /usr/bin/passwd et /usr/bin/so ont plutôt -rwsr-xr-x. Cela signifie que, quel que soit l'utilisateur qui exécute passwd ou Sudo, il s'exécute en tant qu'utilisateur root, car root est le propriétaire de l'exécutable. (Il existe également un bit setgid, qui, lorsqu'il est défini, provoque l'exécution des exécutables avec l'identité de groupe du propriétaire de leur groupe plutôt que celle de l'appelant.)

À l'exception des vulnérabilités de sécurité qui n'ont pas encore été découvertes (ou qui ont été découvertes mais qui n'ont pas encore été corrigées), Sudo et passwd sont sûrs, car ces utilitaires sont très soigneusement écrits, de sorte qu'ils ne peuvent effectuer que les tâches que l'appelant doit effectuer. être autorisé à faire.

/bin/rm ne fonctionne pas de cette façon. Ce n'est pas setuid parce que ce n'est pas nécessaire. Autorisations de répertoire (et occasionnellement, les autorisations de fichier ) contrôlent les fichiers qu'un utilisateur peut supprimer et il n'est pas nécessaire qu'ils deviennent root pour le faire. Juste pour être parfaitement clair, veuillez ne jamais régler le bit setuid sur rm. Les implications en termes de sécurité seraient désastreuses car, peu importe qui exécute rm, c'est comme si root l'avait exécuté! (Des utilitaires tels que Sudo et passwd vérifient ceux qui les exécutent réellement et vérifient que quelque chose est autorisé avant de le faire; rm ne fait rien de tel.)

Le fait de vérifier si le bit setuid (ou setgid) est défini sur un exécutable vous indiquera si le fait de restreindre le nombre de personnes qui l’exécutent peut améliorer la sécurité. Les exécutables qui ne sont pas setuid (ou setgid) n'ont pas de statut particulier et n'importe qui peut simplement les copier et exécuter la copie, apporter leur propre copie depuis un autre ordinateur, écrire un script ou un programme faisant la même chose, ou utiliser un autre programme pour le faire.

Suppression de fichiers sans rm

Le moyen évident de supprimer un fichier sans rm dans Ubuntu consiste à naviguer vers son emplacement dans le navigateur de fichiers graphique (Nautilus, si vous utilisez Unity ou GNOME Shell) et à supprimer le fichier. Il existe également de nombreuses commandes permettant de supprimer un fichier d'un terminal, sans jamais utiliser rm.

Par exemple, pour supprimer un fichier appelé foo.txt dans le répertoire en cours, les commandes suivantes, qui fonctionnent telles quelles sous Ubuntu et ne nécessitent pas d'accès à rm, permettent d'atteindre cet objectif. (Juste pour être sûr, je les ai testés sur a Système minimal 16.04 installé uniquement avec les utilitaires système standard, après avoir supprimé /bin/rm.)

  • unlink foo.txt
  • busybox rm foo.txt
  • Perl -e 'unlink("foo.txt")'
  • python3 -c 'import os; os.remove("foo.txt")' (python au lieu de python3 dans les versions antérieures)

Bien entendu, cette liste est loin d’être complète. Aucune liste complète de telles commandes n'est possible. Empêcher la suppression de fichiers est l’un des objectifs distincts des comptes d’utilisateur et des autorisations de fichiers et de répertoires. Ils travaillent très bien pour l'empêcher. En revanche, modifier la commande rm (pour lui demander un mot de passe, ou de toute autre manière) ou limiter l'accès à rm ne l'empêche pas du tout.

19
Eliah Kagan

Vous pouvez modifier les autorisations sur la commande /bin/rm via la ligne suivante, ce qui empêchera son exécution sans accès Sudo:

Sudo chmod 750 /bin/rm

Ceci les empêche spécifiquement d'utiliser la commande rmfournie par le système. Vous devez savoir que cela ne les empêche pas de supprimer des fichiers par d'autres moyens.

Pour les empêcher également d'utiliser la commande rmdirname__, qui est un moyen courant de supprimer des répertoires, vous pouvez définir les autorisations de la même manière sur son chemin d'exécution:

Sudo chmod 750 /bin/rmdir

Rappelez-vous que vous ne pouvez également utiliser que ces commandes avec les droits Sudo.

Pour le changer si vous ne l'aimez pas ou si d'autres problèmes se produisent, utilisez 755 pour chmodname__

Comme @muru l'a fait remarquer, ce qui précède est une solution très grossière et peut même entraîner la rupture des services système qui ne s'exécutent pas sur le compte racine . Par conséquent, j’ajoute ici une autre option utilisant ACL (listes de contrôle d’accès) pour faire la même chose et probablement beaucoup plus sûre ( bon à lire également et vous pouvez ignorer la partie activation car ACL est généralement installé sur les systèmes Ubuntu. aujourd'hui):

Donc, faire la même chose que ci-dessus juste pour les utilisateurs que vous voulez bloquer serait

Sudo setfacl -m u:<user-name>:- /bin/rm /bin/rmdir

Il suffit de remplacer <user-name> par les noms d'utilisateur que vous souhaitez empêcher d'utiliser les fichiers.

Comme avec chmodname__, l'utilisation de setfacl -m pour empêcher des utilisateurs spécifiques d'exécuter rmet rmdirs'applique à ces commandes fournies par le système uniquement. Cela ne les empêche pas de supprimer vos fichiers et vos dossiers dans Nautilus ou en utilisant d'autres commandes de terminal.

Explication:

  • l'indicateur -m signifie modifier les fichiers ACL.
  • la première partie de la modification, ucorrespond à user. Il peut avoir les valeurs suivantes upour l'utilisateur, gpour le groupe et opour tous les autres
  • la partie médiane <user-name> peut indiquer le nom d'utilisateur ou le nom du groupe en fonction de ce que vous souhaitez modifier. Pour définir les modifications globales, laissez le champ vide.
  • la troisième partie contient le type d'autorisations que vous souhaitez définir. Ici, dans l'exemple, nous souhaitons ne pas définir d'autorisations. Nous avons donc ajouté -. Il peut également contenir les lettres suivantes rpour les autorisations de lecture, wpour les autorisations d'écriture et xnom__ pour l'exécution.
16
Videonauth

C'est une réponse très simple qui empêchera quelqu'un d'utiliser la commande rm sans donner de mot de passe. Ce n'est pas une solution sécurisée et vous devriez implémenter certaines des suggestions alternatives dans les autres réponses.

Cependant, vous pouvez utiliser alias pour modifier le comportement de la commande rm. Essayer:

alias rm="Sudo -l >/dev/null && rm"

Ce que cela fait, c'est quand quelqu'un entre la commande rm, il exécute la commande Sudo -l. Cette commande oblige l'utilisateur à entrer son mot de passe. S'ils l'obtiennent bien, il liste leurs privilèges (nous ignorons cette sortie) et quitte avec le statut 0. S'ils se trompent, il existe avec une erreur.

Nous suivons ensuite la commande Sudo avec un "&&", qui ferme la commande suivante - dans ce cas, "rm" uniquement si la commande précédente quitte avec le statut 0 - c'est-à-dire qu'ils ont obtenu le mot de passe correct.

Pour rendre cela permanent, incluez la commande alias dans ~/.bashrc.

Notez que ceci est très facilement vaincu (par exemple, ils pourraient simplement taper /bin/rm.

8
Nick Sillito

Parfois ce ne sont pas nos amis, nous sommes nos pires ennemis

J'ai écrit un script pour mot de passe protéger rmcomme l'OP a demandé, mais également mis en place des modifications pour vous empêcher de supprimer accidentellement:

  • /
  • /maison
  • /poubelle

Edit: 5 mars 2017 - Changer la méthode de vérification en cours d'exécution dans le terminal.

Créer le script

Utilisez gksu gedit /usr/local/bin/rm et copiez-le dans ces lignes:

#!/bin/bash

tty -s;
if [ "0" == "$?" ]; then Terminal="Y"; else Terminal="N"; fi

if [ $Terminal == "Y" ] ; then
    # Running from terminal don't allow delete of / or /toplevel directory even if Sudo
    for i in ${@:1}
    do
        # Skip options -i -r -v -d 
        if [[ ${i:0:1} != "-" ]] ; then
            # if parameter doesn't begin with '-' it's file or directory, so get real path.
            fullname=$(realpath "$i" 2>&1) # No error messages if file doens't exist
            # We must have at least two `/` in the full path
            levels=$(echo "$fullname" | tr -cd '/' | wc -c)
            if (( $levels == 1 )); then # Test for 1, will be zero when file doesn't exist.
                echo "Attempting to remove top level directory '$fullname'"
                echo "Use 'Sudo /bin/rm $@' instead."
                exit 1 # error
            fi
        fi
    done
fi


if [[ $(id -u) != 0 ]]; then # Only non-root processes enter password (ie "Sudo rm ..." is ok)
  if [ $Terminal == "Y" ] ; then
  # Only running from a terminal needs password (ie not cron)

    # log rm usage to /var/log/syslog
    PARENT_COMMAND="$(ps -o comm= $PPID)"   
    logger "$PARENT_COMMAND"" - rm command was used on file: ""$fullname"

    # Get password
    Password=$(zenity --password --title="Password for rm")
    encryptPassword=$(echo -n "$Password" | md5sum)

echo "md5sum: $encryptPassword" # Comment out after viewing one time and updating line below.

    if [[ "$encryptPassword" != "d2c30dc65e59558c852ea30b7338abbe  -" ]]; then
        echo "Invalid password!"
        exit 1
    fi
  fi # non-terminals can't enter password.
fi # root doesn't need to enter password.

# Call REAL rm command with parameters passed to this wrapper sript
/bin/rm "$@"

exit 0

Remplacez le mot de passe "WE2U" par tout ce que vous voulez et enregistrez le fichier.

Marquer le nouveau script rmcomme exécutable

Marquez le nouveau script rmcomme exécutable à l'aide de:

Sudo chmod +x /usr/local/bin/rm

Comment ça marche

rm password

Sauf si le mot de passe est WE2U , la première fois que vous exécutez le script, vous obtiendrez un "mot de passe invalide". et la clé de cryptage du mot de passe que vous avez entré est affichée. Copiez et collez cette clé de chiffrement du terminal dans le script. Puis commentez la ligne avec l'écho qui affiche la clé de cryptage sur le terminal.

Comme le chemin /usr/local/bin est plus élevé dans la liste que /bin, notre commande rmest appelée. Après avoir obtenu un mot de passe valide, il appelle /bin/rm pour effectuer la suppression réelle.

Comme Thomas Ward l'a souligné dans une autre réponse, si vous deviez faire un Sudo apt-get install ..., le mot de passe pourrait vous être demandé mille fois. Le script vérifie si Sudoest utilisé et ne demande pas de mot de passe. De plus, si rmest appelé depuis l’application graphique, aucun mot de passe n’est requis.

Le script appelle loggerpour enregistrer chaque fois que rma été appelé manuellement à l'aide du terminal. L'utilisation de la commande est enregistrée dans /var/log/syslog.

5
WinEunuuchs2Unix

Une autre alternative serait de créer des copies de sauvegarde de tous les fichiers importants dans un répertoire auquel les utilisateurs non-root n’ont pas accès. Vous pouvez utiliser rsync ou unison pour les synchroniser automatiquement. Assurez-vous simplement qu'au moins un répertoire du chemin de la destination de sauvegarde appartient à root et au mode 700. Cela entraînerait cependant la copie en deux exemplaires de tous les fichiers. Il serait plus sûr de simplement créer un utilisateur invité à utiliser, sauf que vous devez vous rappeler de toujours verrouiller ou vous déconnecter avant de leur donner l'ordinateur ou de le laisser sans surveillance.

3
Random832

Pas la réponse directe à la question que vous cherchez, mais:

Si vos amis suppriment vos fichiers à l’aide de la commande rm, ils sont soit incompétents, saccadés, soit BOFH wannabes qui essaient de vous apprendre à ne pas laisser vos sessions connectées et sans surveillance. Dans tous les cas, la solution est la même: ne laissez pas votre session connectée sans surveillance .

Cela présente l’avantage de ne pas avoir à penser à apporter des modifications spéciales au système chaque fois que vous mettez à niveau ou obtenez un nouveau système, et empêche également les scripts et autres choses que vous utilisez qui reposent sur des commandes se comportant comme prévu d’échouer de manière imprévisible.

Cela présente également l'avantage d'empêcher les "amis" de passer à l'étape suivante. Voulez-vous également "protéger par un mot de passe" la commande mv s’ils décident de déplacer vos fichiers vers/dev/null s’ils découvrent qu’une simple suppression ne fait pas ce qu’ils veulent? Lorsque vous jouez dans un jeu comme celui-ci, le seul coup gagnant est de ne pas jouer.

2
Rob Moir

J'ai une possibilité similaire que j'ai prévue pour. Sur le serveur de fichiers, si le stockage principal de photos est accessible en écriture, certains membres de la famille (moins technique ou par accident) risquent de supprimer quelque chose, de glisser accidentellement dans l’interface utilisateur déplaçant le répertoire ou d’écraser un original avec une version modifiée plutôt que de le renommer. .

J'ai réalisé que je pouvais me protéger contre cela sans rendre les autorisations non écrites pour tous les autres. ZFS crée des instantanés périodiques afin que toute suppression ou tout écrasement accidentel puisse être inversé. (Contrairement à une sauvegarde, un instantané est léger et copie sur écriture afin de ne pas multiplier votre utilisation de stockage.)

ZFS est natif de FreeBSD. Linux a btrfs qui a aussi des instantanés.

1
JDługosz

Une solution très stupide pour un problème très stupide.

Si vous ne souhaitez pas utiliser chmodname___rmname__, rmdirou mv(pour mv filename /dev/null) ou utiliser des ACL, vous pouvez créer un utilisateur factice avec un mot de passe que personne ne vous connait mais alias chaque commande Sudo [user], Créez ensuite des alias pour chaque commande inconnue de vos amis. Ainsi, lorsque vos amis tapent rmname__, le système les invitera à entrer un mot de passe (mais deviner que le mot de passe est incorrect enregistrera la tentative ayant échoué) et vous pourrez toujours taper rmaliasou quoi que vous choisissiez pour réellement supprimer des fichiers.

Ou vous pouvez simplement créer un compte invité qui n'a pas accès à votre répertoire personnel.

0
Andy

Si vous voulez protéger par mot de passe rm, une solution serait de créer un wrapper pour rm qui aurait besoin des privilèges root, et de demander un mot de passe autrement. (REMARQUE: Ce wrapper peut disparaître lorsque le package de coreutils est mis à jour ou réinstallé.) Veuillez également noter que cela ne fait que sécuriser rm. beaucoup d'autres façons de supprimer un fichier.

Ouvrez un terminal et devenez root. Ensuite, exécutez Sudo mv /bin/rm /bin/rmold pour déplacer l'ancien rm à un autre endroit.

Exécutez maintenant Sudo nano /bin/rm pour créer un wrapper.

Dans Nano, tapez ce qui suit:

#!/bin/bash
/bin/rmold "$@"
exit "$?"

Puis maintenez CTRLet appuyez sur Xpour quitter. Appuyez sur Yà l'invite, puis appuyez sur ENTERpour enregistrer le fichier.

Enfin, nous devons lui donner les autorisations appropriées:

Sudo chmod a+x /bin/rm

Et voilà.

0
InitializeSahib