Mes amis continuent de supprimer mes fichiers à l'aide du terminal. Alors s'il vous plaît, aidez-moi en expliquant comment créer un mot de passe pour la rmcommande.

Il n'y a pas de moyen facile de configurer un tel mot de passe sur la rmcommande elle-même, non sans beaucoup de piratage de code qui va probablement casser des choses comme l' apt-getinstallation de packages et la suppression de fichiers, et vous obliger à entrer le mot de passe mille fois, ou potentiellement perturber 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'utilisateurs et plusieurs jeux d'autorisations d'accès et restreindre l'accès à différentes sections de données, telles que votre répertoire personnel, afin qu'ils ne puissent pas y accéder.

(L'autre option est les comptes d'utilisateurs individuels pour chaque utilisateur, puis les listes de contrôle d'accès, comme cela est détaillé dans l' autre réponse publiée par Videonauth )

Voici le problème principal - vous laissez vos amis utiliser votre système. Cela a de nombreuses implications en matière de sécurité - le concept de «toute personne ayant un accès physique à la boîte va pouvoir contrôler le système et effectuer n'importe quelle tâche» 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.

La seule façon vraiment sensée de le faire est de ne pas donner à vos amis l'accès à votre ordinateur, et de leur donner un "système" invité "dédié qu'ils peuvent utiliser, sur lequel vous ne vous souciez pas vraiment 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, votre seule option vraiment sûre consiste à configurer plusieurs comptes d'utilisateurs, un pour chaque utilisateur, avec des dossiers de départ différents, et ne leur permettez pas d'accéder à votre propre répertoire de base ou à la maison de tout autre utilisateur répertoires. Et puis gardez tout ce que vous ne voulez pas qu'ils touchent dans votre répertoire personnel, et ne leur donnez pas sudoaccès, le rootmot de passe ou ne partagez pas votre mot de passe avec eux.

Voici comment procéder:

Disons que mon nom est "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 à refuser l'accès à mon répertoire personnel à quiconque sauf moi. C'est pour permettre à d'autres utilisateurs de ne pas supprimer vos fichiers, mais aussi pour empêcher d'autres utilisateurs de fouiner dans votre répertoire personnel et de voir quels types de choses vous avez dans votre répertoire personnel:

chmod 750 /home/Foo

La deuxième étape consiste à créer un compte utilisateur pour "Bar" (ne tapez PAS ce qui est entre parenthèses ci-dessous, c'est à titre informatif uniquement). De cette façon, nous pouvons nous assurer qu'il dispose de son propre ensemble distinct 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 non plus faire levier sur leurs fichiers. C'est juste rendre les choses égales.

sudo chmod 750 /home/Bar

Lavez-vous les mains, rincez-les bien, puis répétez ces étapes pour le nombre d'utilisateurs que vous avez sur le système. Ils ne pourront pas accéder à vos fichiers, et puisque vous ne leur accordez pas de privilèges d'administrateur, ils ne peuvent pas supprimer vos fichiers sans tenter de sudole faire - puisque vous ne le permettez pas, ils ne peuvent pas touchez vos affaires. Et ils ne pourront pas non plus voir vos fichiers, sans devenir superutilisateur, ce qui n'arrivera pas ici.

RAPPELEZ-VOUS TOUJOURS: En donnant à quelqu'un un accès physique à la machine, ou un accès en général, vous allez 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 continue de se vérifier. Donner à vos amis l'accès à votre ordinateur mettra toujours vos données en péril, alors donnez-leur leur propre système pour s'amuser, ou tout simplement ne leur donnez pas accès à votre machine.

Juste une note sur le cryptage du disque

Bien que le chiffrement du disque fonctionne bien pour protéger vos données contre un tiers, il existe des limitations.

1. Si le système est sous tension, le disque est déjà déchiffré, vous êtes donc à risque.
2. Certains systèmes ont des approches de chiffrement de disque brisées . Par exemple, certains systèmes Acer utilisent votre mot de passe pour autoriser uniquement le cryptage / décryptage et utiliser des mots de passe codés en dur, ou utiliser un cryptage faible qui est facilement craqué.
3. Il existe toujours des méthodes pour pénétrer dans les «clés» ou 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 de la RAM ne soient «disparues» ou détériorées. (Je ne vais pas aller en profondeur sur ces derniers , mais ces risques ne existent).
4. L'accès physique à la machine, que le système soit chiffré ou non, mettra toujours vos données en danger. Ne donnez pas un accès physique (ou un accès réseau à distance) à des personnes auxquelles vous ne souhaitez pas potentiellement donner un accès complet à votre système.

Bien que Disk Encryption ne résout pas ces problèmes, il crée des couches supplémentaires de maux de tête pour un acteur de menace. Quelqu'un qui est un méchant peut abandonner s'il est crypté, ou il peut vous torturer (faire la queue dans la bande dessinée XKCD Security obligatoire ).

Par conséquent, si votre système est crypté, mais que vous laissez d'autres utilisateurs l'utiliser, soit ils ont un mot de passe à décrypter, soit vous laissez votre ordinateur portable décrypté afin qu'ils puissent 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.

Il ne s'agit peut-être pas vraiment de la rmcommande, car il existe des moyens faciles de supprimer des fichiers sans l'utiliser . Si le problème est que vos amis rmutilisent involontairement la commande, des solutions qui restreignent spécifiquement l'utilisation de cette commande ou la font fonctionner d'une manière différente peuvent être utiles. En revanche, si le problème est que vos amis traitent délibérément vos données d'une manière que vous ne voulez pas, alors vous devez mettre en œuvre des mesures de sécurité réelles , et aucune solution qui se concentre sur la rmcommande elle-même (ou sur un ensemble discret de commandes) 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 savent que vous ne voulez pas qu'ils suppriment vos fichiers, il y a 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 répondre à vos souhaits sur la façon dont ils traitent vos données lorsqu'ils utilisent votre ordinateur. La seule solution à ce problème consiste à utiliser une véritable mesure de sécurité efficace , comme Thomas Ward l'a expliqué en détail . Souvent, la meilleure mesure est de les empêcher d'utiliser votre ordinateur. Mais les obliger à utiliser leurs propres comptes d'utilisateurs peut fournir une certaine protection.

2. Ils pourraient le faire par erreur. Dans ce scénario, vos amis sont extrêmement sujets aux accidents et continuent d'exécuter des rmcommandes qu'ils auraient souhaité ne pas avoir. Ils veulent vous traiter vous et vos données avec respect, mais ils sont vraiment mauvais à le faire dans la pratique car ils continuent à exécuter la mauvaise commande, à supprimer le mauvais fichier ... ou quelque chose comme ça. Bien qu'il serait bon de croire que c'est ce qui se passe, je vous mets en garde contre l'hypothèse que les personnes qui continuent de supprimer vos données après que vous leur avez dit d'arrêter fonctionnent sans mauvaise volonté.

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

Si la situation est vraiment n ° 2 - vos amis n'essaient pas de supprimer vos fichiers, mais ont simplement besoin d'aide pour ne pas les supprimer accidentellement , et la seule façon de les supprimer accidentellement est de mal utiliser par inadvertance un petit nombre de commandes (comme rm) qu'ils ont particulièrement du mal à utiliser correctement - alors les techniques dans la réponse de Videonauth peuvent être d'une certaine utilité. Mais vous devez comprendre qu'il ne s'agit pas de mesures de sécurité, car la rmcommande n'est qu'un des nombreux moyens simples de supprimer des fichiers . Voir ci-dessous pour plus de détails.

Je vous recommande de vous demander: "Ma situation est-elle essentiellement la même que si moi, plutôt que les autres personnes qui utilisent mon ordinateur, j'utilisais rmmal?"

Si la réponse est non , c'est une question de sécurité de l'information et vous devez empêcher vos amis d'utiliser votre compte d'utilisateur. Si la réponse est oui , alors vous pouvez utiliser les mêmes approches que vous utiliseriez si vous étiez celui qui faisait un mauvais usage rm:

• Éducation. Vos amis doivent 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 d'utilisateur séparés), vous pouvez rendre plus difficile la suppression accidentelle de fichiers en le rendant si juste s'exécuter seul, sans autre action, ne sera pas immédiatement supprimé . La réponse de Videonauth donne une approche à cela. Dans cette réponse, j'en présente un autre.rm filefile

Mais même si vos amis n'essaient pas de faire quoi que ce soit de mal, vous devriez toujours envisager de les faire utiliser leurs propres comptes d'utilisateurs distincts . Cela résoudra toujours le problème - les mêmes mesures de sécurité qui protègent les données de la destruction délibérée le protégeront également de la destruction involontaire. Même sans intention malveillante, si quelqu'un continue de faire quelque chose que vous ne voulez pas qu'il fasse, alors vous ne pouvez pas lui faire confiance pour s'abstenir de faire cette chose.

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

Pour aider les utilisateurs à éviter de supprimer accidentellement des fichiers avec rm, vous pouvez créer rmun alias de shell qui s'exécute réellement rm -i. Si vous passez l' -iindicateur à rm, il invite l'utilisateur à supprimer chaque fichier (voir man rm).

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

Cela n'offre aucune sécurité réelle et n'est pas à toute épreuve pour éviter les erreurs, car:

• Ils peuvent choisir d'aller de l'avant avec la suppression, lorsqu'ils y sont invités.
• Ils peuvent contourner l'alias de nombreuses manières, notamment en l'exécutant /bin/rmou en le désaliasant ( unalias rm).
• Il existe de nombreuses situations où l'expansion d'alias ne se produit pas et, dans ces situations rm, ne sera pas exécutée avec -i.
• Ils peuvent toujours supprimer des fichiers en utilisant l'une des techniques pour le faire 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 d'une 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 rmcommande fournie par le système :

• Le repliement rmvers rm -iest moins efficace pour prévenir les erreurs - jusqu'à ce qu'ils passent à l'utilisation d'une autre technique pour supprimer des fichiers. À ce stade, les empêcher d'utiliser rmsera totalement inefficace, même s'ils n'essaient pas de faire quoi que ce soit de mal, car ils utiliseront vraisemblablement unlink(ou l'une des innombrables autres commandes qui suppriment un fichier) avec une absence de réflexion égale.

• D'un autre côté, parce que l'expansion d'alias ne se produit que dans certaines situations - en gros, une utilisation interactive ordinaire du shell - vos amis peuvent penser qu'ils vont être invités lorsqu'ils ne le sont pas vraiment (car la commande est dans un script, par exemple, ou provenant d'un autre shell). La voie de Videonauth n'a pas ce problème, ce qui est un avantage objectif de cette méthode alias rm='rm -i'.

• Lorsqu'un script s'exécute, à moins qu'il ne soit délibérément écrit pour utiliser des alias, vos alias n'y sont pas développés. Cela signifie que l' aliasing rmà rm -iest très peu susceptible de casser quoi que ce soit. C'est un avantage objectif de alias rm='rm -i'.

rm ne peut rien faire qu'un autre programme parfaitement ordinaire ne puisse faire.

Il n'y a vraiment rien de spécial rm. Il s'agit d'un moyen pratique et auto-documenté de supprimer des fichiers, donc restreindre l'accès à celui-ci risque de casser de nombreux scripts qui en dépendent. Mais c'est loin d'être le seul moyen de supprimer des fichiers - c'est juste un programme ordinaire.

Quelques commandes exécutent une tâche qu'un utilisateur limité (non root ) ne peut pas exécuter sans les exécuter. Par exemple, sudovous permet d'exécuter des programmes en tant qu'autre utilisateur, après avoir vérifié que vous êtes autorisé à le faire. passwdmodifie la base de données où les mots de passe des utilisateurs sont stockés, mais vous permet uniquement de changer votre propre mot de passe (sauf si vous êtes root, auquel cas vous pouvez changer le mot de passe de n'importe qui).

/usr/bin/sudoet /usr/bin/passwdpeut le faire car ils ont le bit setuid défini, comme le montre le squi 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 cela /bin/rmn'a pas s: ses autorisations sont -rwxr-xr-x, while /usr/bin/passwdet /usr/bin/sohave à la -rwsr-xr-xplace. Cela fait en sorte que, peu importe qui s'exécute passwdou 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, une fois défini, fait exécuter les exécutables avec l'identité de groupe de leur propriétaire de 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) sudoet qui passwdsont sûres car ces utilitaires sont très soigneusement écrits afin qu'ils ne puissent faire que des choses que l'appelant devrait être autorisé faire.

/bin/rmne fonctionne pas de cette façon. Ce n'est pas setuid parce que ce n'est pas nécessaire. Les autorisations de répertoire (et parfois les autorisations de fichier ) contrôlent les fichiers qu'un utilisateur peut supprimer, et ils n'ont pas besoin de devenir root pour le faire. Juste pour être parfaitement clair, veuillez ne jamais activer le bit setuidrm . Les implications pour la sécurité seraient désastreuses, depuis lors, peu importe qui s'exécute rm, c'est comme si root l'exécutait! (Les utilitaires aiment sudoet passwdvérifient qui les exécute vraiment et vérifient que quelque chose est autorisé avant de le faire; rmne fait rien de tel.)

Vérifier si le bit setuid (ou setgid) est défini sur un exécutable vous dira si restreindre qui peut l'exécuter a une chance d'améliorer la sécurité. Les exécutables qui ne sont pas setuid (ou setgid) n'ont pas de statut spécial, et n'importe qui peut simplement les copier et exécuter la copie, apporter leur propre copie à partir d'une autre machine, écrire un script ou un programme qui fait la même chose, ou utiliser un autre programme pour le faire.

Suppression de fichiers sans rm

La manière évidente de supprimer un fichier sans rmdans Ubuntu est de naviguer vers son emplacement dans le navigateur de fichiers graphique (Nautilus, si vous utilisez Unity ou GNOME Shell) et de supprimer le fichier. Il existe également de nombreuses commandes qui peuvent être utilisées pour supprimer un fichier d'un terminal, sans jamais l'utiliser rm.

Par exemple, pour supprimer un fichier appelé foo.txtdans le répertoire courant, les commandes suivantes, qui fonctionnent immédiatement sur Ubuntu et ne nécessitent pas d'accès à rm, y parviendront. (Juste pour être sûr, je les ai testés sur un système minimal 16.04 installé avec uniquement les utilitaires système standard, après la suppression /bin/rm.)

• unlink foo.txt
• busybox rm foo.txt
• perl -e 'unlink("foo.txt")'
• python3 -c 'import os; os.remove("foo.txt")'( pythonau lieu des python3anciennes versions)

Cette liste est, bien entendu, loin d'être complète. Aucune liste complète de ces commandes n'est possible. La prévention de la suppression de fichiers est l'une des choses que les comptes d'utilisateurs distincts et les autorisations de fichiers et de répertoires existent. Ils fonctionnent très bien pour l'empêcher. En revanche, changer la rmcommande (pour qu'elle nécessite un mot de passe ou de toute autre manière) ou restreindre l'accès rmne l'empêche pas du tout.

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

sudo chmod 750 /bin/rm

Cela les empêche spécifiquement d'utiliser la rmcommande fournie 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 rmdircommande, 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 exécutable:

sudo chmod 750 /bin/rmdir

Rappelez-vous également que vous ne pouvez également utiliser ces commandes qu'avec des droits sudo.

Pour le modifier si vous ne l'aimez pas ou si d'autres problèmes surviennent, utilisez 755pourchmod

Comme l'a souligné @muru, ce qui précède est une solution très grossière et peut même interrompre les services système qui ne s'exécutent pas sur le compte root . 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ûr ( bon à lire également et vous pouvez ignorer la partie d'activation car ACL est généralement installé sur les systèmes Ubuntu de nos jours):

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

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

Remplacez simplement <user-name>par les noms d'utilisateur réels que vous souhaitez empêcher d'utiliser les fichiers.

Comme avec chmod, setfacl -mpour empêcher des utilisateurs spécifiques de s'exécuter rmet rmdirs'applique uniquement aux commandes fournies par le système. Il ne les empêche pas de supprimer vos fichiers et dossiers dans Nautilus ou en utilisant d'autres commandes de terminal.

Explication:

• le -mdrapeau signifie modifier les fichiers ACL.
• la première partie du changement, les ustands pour l'utilisateur. Il peut avoir les valeurs suivantes upour l'utilisateur, gpour le groupe et opour tous les autres
• la partie centrale <user-name>peut saisir le nom d'utilisateur ou le nom de groupe réel en fonction de ce que vous souhaitez modifier. Pour définir les modifications globales, laissez-le vide.
• la troisième partie contient le type d'autorisations que vous souhaitez définir. Ici, dans l'exemple, nous ne voulons définir aucune autorisation, nous mettons donc -, il peut également contenir les lettres suivantes rpour les autorisations de lecture, wpour les autorisations d'écriture et xpour l'exécution.

Il s'agit d'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ûre et vous devriez implémenter certaines des suggestions alternatives dans les autres réponses.

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

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

Ce que cela signifie, c'est que lorsque quelqu'un entre la commande rm, il exécute la commande sudo -l. Cette commande oblige l'utilisateur à saisir son mot de passe. S'ils le font correctement, il répertorie leurs privilèges (nous rejetons cette sortie) et se termine avec le statut 0, s'ils se trompent, il existe avec une erreur.

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

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.

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

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

• /
• /domicile
• /poubelle

Edit: 5 mars 2017 - Changez la méthode de vérification si vous utilisez le terminal.

Créer le script

Utilisez gksu gedit /usr/local/bin/rmet copiez 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

Changez le mot de passe "WE2U" en ce que vous voulez et enregistrez le fichier.

Marquer le nouveau rmscript comme exécutable

Marquer le nouveau rmscript comme exécutable en utilisant:

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

Comment ça marche

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 pour le mot de passe que vous avez entré s'affiche. Copiez et collez cette clé de chiffrement du terminal dans le script. Puis commentez la ligne avec l'écho qui a affiché la clé de cryptage sur le terminal.

Parce que le chemin /usr/local/binest plus haut sur la liste que /binnotre commande rmn'est appelée. Après avoir obtenu un mot de passe valide, il appelle /bin/rmpour faire la vraie suppression.

Comme l'a souligné Thomas Ward dans une autre réponse, si vous faisiez cela, sudo apt-get install ...on pourrait vous demander un mot de passe mille fois. Le script vérifie s'il sudoest utilisé et ne demande pas de mot de passe. De plus, si rmest appelé depuis l'application GUI, aucun mot de passe n'est requis.

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

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 rsyncou unisonpour les synchroniser automatiquement, assurez-vous simplement qu'au moins un répertoire dans le chemin vers la destination de sauvegarde est détenu par root et en mode 700. Cela entraînerait cependant deux copies 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.

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

Si vos amis suppriment vos fichiers à l'aide de la rmcommande, alors vos amis sont soit incompétents, des imbéciles, soit ce sont des aspirants BOFH 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 et sans surveillance .

Cela a l'avantage de ne pas avoir à se rappeler d'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 de ne pas échouer de manière imprévisible.

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

J'ai une possibilité similaire que je prévoyais. Sur le serveur de fichiers, si le stockage principal des photos est accessible en écriture, une personne de la famille (moins technique ou accidentelle) pourrait supprimer quelque chose, faire glisser accidentellement dans l'interface graphique qui déplace le répertoire ou écraser un original avec une version modifiée plutôt que de renommer .

J'ai réalisé que je pouvais me protéger contre cela sans rendre les autorisations inscriptibles pour tout le monde. ZFS crée des instantanés périodiques afin que toute suppression ou écrasement accidentel puisse être annulé. (Contrairement à une sauvegarde, un instantané est léger et copie sur écriture, il ne multiplie donc pas votre utilisation du stockage.)

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

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

Si vous ne voulez pas chmod rm, rmdirou mv(pour mv filename /dev/null) ou utiliser des ACL, vous pouvez créer un utilisateur factice avec un mot de passe personne mais vous connaissez et alias chaque commande sudo [user], puis créer des alias pour chaque commande que vos amis ne connaissent pas . De cette façon, lorsque vos amis tapent, rmle système leur demandera un mot de passe (mais deviner le mauvais mot de passe enregistrera la tentative échouée), et vous pouvez toujours taper rmaliasou tout ce que vous choisissez pour supprimer réellement les fichiers.

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

Si vous souhaitez protéger rm par mot de passe, une solution serait de créer un wrapper pour rm qui nécessiterait des privilèges root, et de demander un mot de passe dans le cas contraire. (REMARQUE: ce wrapper peut disparaître lorsque le package coreutils est mis à jour ou réinstallé.) De plus, veuillez noter que cela ne sécurise que rm, il existe encore de nombreuses autres façons de supprimer un fichier.

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

Maintenant, exécutez sudo nano /bin/rmpour créer un wrapper.

Dans Nano, tapez ce qui suit:

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

Maintenez ensuite la CTRLtouche enfoncée et appuyez sur Xpour quitter. Appuyez sur Ylorsque vous y êtes invité, puis appuyez sur ENTERpour enregistrer le fichier.

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

sudo chmod a+x /bin/rm

Et voilà.