I miei amici continuano a cancellare i miei file usando il terminale. Quindi per favore aiutatemi spiegando come creare una password per il rmcomando.

Non esiste un modo semplice per impostare una tale password sul rmcomando stesso, non senza un sacco di hacking del codice che probabilmente romperà cose come l' apt-getinstallazione di pacchetti e la rimozione di file e ti costringe a inserire la password mille volte, o potenzialmente a interrompere accedere al comando alle persone che ne avrebbero bisogno (come te, per eliminare i tuoi file). Puoi fare questo avendo più account utente e più set di autorizzazioni di accesso e limitando l'accesso a diverse sezioni di dati, come la tua home directory in modo che non possano accedervi.

(L'altra opzione è rappresentata dai singoli account utente per ciascun utente, quindi dagli elenchi di controllo degli accessi, come dettagliato nell'altra risposta che è stata pubblicata da Videonauth )

Ecco il problema principale: permetti ai tuoi amici di usare il tuo sistema. Ciò ha numerose implicazioni per la sicurezza: il concetto di "chiunque abbia accesso fisico al box sarà in grado di controllare il sistema e svolgere qualsiasi attività" è un Mantra di sicurezza IT, motivo per cui non "condividi" l'accesso ai sistemi fisici tranne con personale autorizzato di fiducia.

L'unico modo veramente sano per farlo è quello di non consentire ai tuoi amici di accedere al tuo computer e dare loro un "sistema" Ospite "dedicato che possono usare, che non ti interessa davvero tanto dei file. Questo è il modo più "sicuro" per proteggere i tuoi file.

Naturalmente, se questa non è un'opzione, l'unica opzione davvero sicura è quella di configurare più account utente, uno per ciascun utente, con cartelle home diverse e non consentire loro di accedere alla propria directory home o l'accesso alla home di qualsiasi altro utente le directory. E poi mantieni tutto ciò che non vuoi che tocchi nella tua home directory e non concedi loro l' sudoaccesso, la rootpassword o condividi la tua password con loro.

Ecco come lo faresti:

Diciamo che il mio nome è "Foo" e voglio che l'utente "Bar", un amico, usi il mio sistema ma non acceda ai miei file. Il primo passo è negare l'accesso a chiunque tranne me alla mia home directory. Questo per consentire ad altri utenti di non eliminare i tuoi file, ma anche per impedire ad altri utenti di curiosare nella tua home directory e vedere quali tipi di cose hai nella tua home directory:

chmod 750 /home/Foo

Il secondo passo è creare un account utente per "Bar" (NON digitare ciò che è tra parentesi qui sotto, è solo a scopo informativo). In questo modo, possiamo assicurarci che abbia un proprio set separato di diritti di accesso:

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)

Il terzo passo è quindi limitare anche la loro home directory in modo che nessuno possa fare leva sui loro file. Questo sta solo rendendo le cose uguali.

sudo chmod 750 /home/Bar

Lavati le mani, risciacqua bene, quindi ripeti questi passaggi per quanti utenti hai sul sistema. Non saranno in grado di accedere ai tuoi file e dal momento che non darai loro i privilegi di amministratore, non possono eliminare i tuoi file senza tentare sudodi farlo - dal momento che non lo permetti, non possono tocca le tue cose. E non saranno neanche in grado di vedere i tuoi file, senza diventare superutente, cosa che non accadrà qui.

RICORDA SEMPRE QUESTO: Dando a qualcuno l'accesso fisico alla macchina, o l'accesso in generale, metterai a rischio i tuoi file e dati. Questo è un fatto ampiamente accettato nel mondo della sicurezza IT e uno che continua a essere vero. Consentire ai tuoi amici di accedere al tuo computer metterà sempre a rischio i tuoi dati, quindi dai loro il loro sistema con cui scherzare o semplicemente non concedi loro l'accesso al tuo computer.

Solo una nota sulla crittografia del disco

Mentre la crittografia del disco funziona bene per proteggere i tuoi dati da terze parti, ci sono delle limitazioni.

1. Se il sistema è acceso, il disco è già decrittografato, quindi sei a rischio.
2. Alcuni sistemi si sono rotti approcci di crittografia del disco . Ad esempio, alcuni sistemi Acer utilizzano la password per autorizzare la crittografia / decrittografia e utilizzare password hardcoded o utilizzare una crittografia debole che è facilmente crackabile.
3. Esistono sempre metodi per entrare nelle "chiavi" o tentare di estrarle dalla memoria subito dopo lo spegnimento di un sistema, ma prima che i dati della RAM siano "spariti" o deteriorati. (Non voglio andare in profondità su questi, ma questi rischi farlo esistere).
4. L'accesso fisico alla macchina, sia che il sistema sia crittografato o meno, metterà sempre a rischio i tuoi dati. Non concedere l'accesso fisico (o l'accesso alla rete remota) a persone alle quali non si desidera potenzialmente dare pieno accesso al proprio sistema.

Mentre Disk Encryption non risolve questi problemi, mette un ulteriore livello di mal di testa per un attore di minacce. Qualcuno che è un cattivo ragazzo potrebbe rinunciare se è crittografato o potrebbe torturarti (coda obbligatoria del fumetto XKCD Security ).

Pertanto, se il tuo sistema è crittografato, ma stai permettendo ad altri utenti di usarlo, o hanno una password per decrittografare o stai lasciando il tuo laptop decodificato in modo che possano SSH o avere accesso fisico. In entrambi questi casi, è male.

Detto questo, se il tuo sistema non è crittografato, questa sezione non ha rilevanza per te.

Questo potrebbe non riguardare davvero il rmcomando, poiché ci sono modi semplici per eliminare i file senza usarlo . Se il problema è che i tuoi amici rmusano involontariamente il comando, le soluzioni che limitano l'uso specifico di quel comando o lo fanno funzionare in modo diverso potrebbero essere di aiuto. Al contrario, se il problema è che i tuoi amici trattano deliberatamente i tuoi dati in un modo che non desideri, allora devi implementare misure di sicurezza effettive e nessuna soluzione che si concentri sul rmcomando stesso (o su qualsiasi set discreto di comandi) ti terrà al sicuro.

Devi controllare l'accesso o semplicemente prevenire errori onesti?

Supponendo che i tuoi amici sappiano che non vuoi che cancellino i tuoi file, ci sono due possibilità:

1. Potrebbero farlo apposta. In questo scenario, i tuoi amici eliminano deliberatamente i tuoi file e non puoi nemmeno fidarti di loro per provare a soddisfare i tuoi desideri su come trattano i tuoi dati quando usano il tuo computer. L'unica soluzione a questo problema è utilizzare un'effettiva misura di sicurezza efficace , come Thomas Ward ha spiegato in dettaglio . Spesso la misura migliore è impedire loro di utilizzare il computer. Ma farli utilizzare i propri account utente può fornire una certa protezione.

2. Potrebbero farlo per errore. In questo scenario, i tuoi amici sono estremamente inclini agli incidenti e continuano a eseguire rmcomandi che non avrebbero voluto. Vogliono trattare te e i tuoi dati con rispetto, ma sono davvero cattivi nel farlo in pratica perché continuano a eseguire il comando sbagliato, a eliminare il file sbagliato ... o qualcosa del genere. Anche se sarebbe bello credere che questo è ciò che sta accadendo, ti avverto di non dare per scontato che le persone che continuano a eliminare i tuoi dati dopo che hai detto loro di smettere stanno funzionando senza cattiva volontà.

   Inoltre, anche se le loro intenzioni sono buone, fornire loro account utente separati è ancora il modo più infallibile per impedire loro di eliminare i file, oltre a non consentire loro di utilizzare il computer.

Se la situazione è davvero n. 2 - i tuoi amici non stanno cercando di eliminare i tuoi file ma hanno solo bisogno di aiuto per non cancellarli accidentalmente , e l'unico modo in cui li cancellano accidentalmente è attraverso l'uso involontario di un piccolo numero di comandi (come rm) che hanno particolari problemi nell'utilizzare correttamente, quindi le tecniche nella risposta di Videonauth potrebbero essere di qualche utilità. Ma devi capire che non sono misure di sicurezza, perché il rmcomando è solo uno dei tanti modi semplici per eliminare i file . Vedi sotto per i dettagli.

Ti consiglio di chiederti: "La mia situazione è sostanzialmente la stessa di se io, piuttosto che le altre persone che usano il mio computer, stavo usando in rmmodo errato?"

Se la risposta è no , questa è una questione di sicurezza delle informazioni e devi impedire ai tuoi amici di utilizzare il tuo account utente. Se la risposta è sì , allora è possibile utilizzare gli stessi approcci usereste se si fossi quello abuso rm:

• Formazione scolastica. I tuoi amici devono sapere cosa stanno facendo e come evitarlo.
• Modifiche all'interfaccia. Senza togliere l'effettiva capacità di eliminare i file (che richiede account utente separati), puoi rendere più difficile l' eliminazione accidentale dei file rendendola così in esecuzione da sola, senza ulteriori azioni, non eliminerà immediatamente . La risposta di Videonauth fornisce un approccio a questo. In questa risposta, ne presento un altro.rm filefile

Ma anche se i tuoi amici non stanno provando a fare qualcosa di sbagliato, dovresti comunque considerare di farli usare i loro account utente separati . Ciò risolverà comunque il problema: le stesse misure di sicurezza che proteggono i dati dalla distruzione intenzionale li proteggeranno anche dalla distruzione involontaria. Anche senza intenti maliziosi, se qualcuno continua a fare qualcosa che non vuoi che faccia, non puoi fidarti che si astengano dal fare quella cosa.

Fare una rmrichiesta prima dell'eliminazione può aiutare a prevenire alcuni errori.

Per aiutare le persone a evitare l' eliminazione accidentale di file rm, è possibile creare rmun alias di shell che viene effettivamente eseguito rm -i. Passando il -iflag per rmindurlo a richiedere all'utente prima di eliminare ogni file (vedi man rm).

Puoi farlo (per il tuo account utente) aggiungendo alias rm='rm -i'al tuo .bash_aliaseso al .bashrcfile. Vedi questa domanda e quella per i dettagli. Questo avrà effetto per le tue shell bash appena aperte.

Ciò non fornisce alcuna sicurezza effettiva e non è nemmeno infallibile nel prevenire errori, perché:

• Possono scegliere di procedere con l'eliminazione, quando richiesto.
• Possono bypassare l'alias in numerosi modi, anche eseguendolo /bin/rmo annullandolo ( unalias rm).
• Esistono molte situazioni in cui non si verifica l'espansione dell'alias e in queste situazioni rmnon verranno eseguite -i.
• Possono ancora eliminare i file usando una delle tecniche per farlo che non richiedono rm(come nel caso dell'approccio di Videonauth - vedi sotto).
• Possono comunque danneggiare i dati senza eliminare alcun file, ad esempio sovrascrivendoli o modificandone in altro modo il contenuto (come nel caso dell'approccio di Videonauth).

Ma se non hai bisogno di sicurezza effettiva (vedi sopra), allora questa potrebbe essere la strada da percorrere. In confronto all'approccio di impedire ai tuoi amici di utilizzare il rmcomando fornito dal sistema :

• Aliasing rma rm -iè meno efficace nel prevenire gli errori - fino a quando si muovono su di utilizzare qualche altra tecnica per rimuovere i file. A quel punto, impedirgli di usare rmsarà del tutto inefficace, anche se non stanno provando a fare qualcosa di sbagliato, dal momento che presumibilmente useranno unlink(o uno qualsiasi degli innumerevoli altri comandi che rimuovono un file) con uguale spensieratezza.

• D'altra parte, poiché l'espansione dell'alias si verifica solo in alcune situazioni - approssimativamente parlando, un uso interattivo ordinario della shell - i tuoi amici potrebbero pensare che verrà loro richiesto quando non sono realmente richiesti (perché il comando è in uno script, ad esempio, o rilasciato da una shell diversa). Il modo di Videonauth non ha questo problema, che è un vantaggio oggettivo di quel metodo alias rm='rm -i'.

• Quando viene eseguito uno script, a meno che non sia scritto deliberatamente per utilizzare gli alias, i tuoi alias non vengono espansi in esso. Ciò significa che aliasing rma rm -iè molto improbabile che rompere nulla. Questo è un vantaggio oggettivo di alias rm='rm -i'.

rm non può fare nulla che nessun altro programma perfettamente normale non possa fare.

Non c'è davvero niente di speciale rm. È un modo conveniente e auto-documentante per rimuovere i file, quindi limitare l'accesso ad esso rischia di rompere numerosi script che si basano su di esso. Ma è tutt'altro che l'unico modo per eliminare i file: è solo un normale programma.

Alcuni comandi eseguono attività che un utente limitato (non root ) non può eseguire senza eseguirle. Ad esempio, sudoti consente di eseguire programmi come un altro utente, dopo aver verificato che ti sia permesso farlo. passwdmodifica il database in cui sono archiviate le password degli utenti, ma ti consente solo di cambiare la tua password (a meno che tu non sia root, nel qual caso puoi cambiare la password di chiunque).

/usr/bin/sudoe /usr/bin/passwdpuò farlo perché hanno il bit setuid impostato, come mostrato da quello sche appare nella colonna più a sinistra quando si esegue 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

Si noti che /bin/rmnon ha s: i suoi permessi sono -rwxr-xr-x, mentre /usr/bin/passwde /usr/bin/sohanno -rwsr-xr-xinvece. Questo lo rende tale, indipendentemente da chi esegue passwdo sudo, in realtà viene eseguito come utente root, poiché root è il proprietario dell'eseguibile. (Esiste anche un bit setgid che, se impostato, fa eseguire gli eseguibili con l'identità del gruppo del proprietario del gruppo piuttosto che quella del chiamante.)

Ad eccezione di eventuali vulnerabilità di sicurezza che non sono state ancora scoperte (o che sono state scoperte ma non sono ancora state patchate), sudoe passwdsono sicure perché tali utilità sono scritte con molta attenzione in modo che possano fare solo cose che il chiamante dovrebbe essere autorizzato fare.

/bin/rmnon funziona in questo modo. Non è impostato perché non deve essere. I permessi della directory (e occasionalmente i permessi dei file ) controllano quali file un utente può cancellare e non hanno bisogno di diventare root per farlo. Solo per essere perfettamente chiari, per favore non impostare mai il bit setuidrm . Le implicazioni per la sicurezza sarebbero disastrose, da allora, indipendentemente da chi corre rm, è come se fosse stato root! (Ai programmi di utilità piacciono sudoe passwdcontrollano chi li sta realmente eseguendo e controllano che qualcosa sia permesso prima di farlo; rmnon fa nulla del genere.)

Controllare se il bit setuid (o setgid) è impostato su un eseguibile ti dirà se limitare chi può eseguirlo può migliorare la sicurezza. Gli eseguibili che non sono setuid (o setgid) non hanno alcuno stato speciale e chiunque può semplicemente copiarli ed eseguire la copia, portare la propria copia da un'altra macchina, scrivere uno script o un programma che fa la stessa cosa, o usare un altro programma per farlo.

Eliminazione di file senza rm

Il modo ovvio per eliminare un file senza rmUbuntu è quello di navigare fino alla sua posizione nel browser di file grafico (Nautilus, se si utilizza Unity o GNOME Shell) ed eliminare il file. Esistono anche numerosi comandi che possono essere utilizzati per eliminare un file da un terminale, senza mai utilizzarlo rm.

Ad esempio, per rimuovere un file chiamato foo.txtnella directory corrente, i seguenti comandi, che funzionano immediatamente su Ubuntu e non richiedono l'accesso rm, lo faranno. (Per essere sicuro, li ho testati su un sistema minimo 16.04 installato con solo le utility di sistema standard, dopo l'eliminazione /bin/rm.)

• unlink foo.txt
• busybox rm foo.txt
• perl -e 'unlink("foo.txt")'
• python3 -c 'import os; os.remove("foo.txt")'( pythonanziché python3nelle versioni precedenti)

Tale elenco, ovviamente, non è affatto completo. Non è possibile un elenco completo di tali comandi. Prevenire l'eliminazione dei file è una delle cose che esistono account utente separati e autorizzazioni per file e directory da raggiungere. Funzionano molto bene per prevenirlo. Al contrario, cambiando il rmcomando (per renderlo necessario una password, o in qualsiasi altro modo) o limitando l'accesso per rmnon impedirlo affatto.

È possibile modificare le autorizzazioni sul /bin/rmcomando tramite la seguente riga che ne impedirà l'esecuzione senza accesso sudo:

sudo chmod 750 /bin/rm

Ciò impedisce loro di utilizzare il rmcomando fornito dal sistema. Dovresti essere consapevole che non impedisce loro di eliminare i file in altri modi.

Per impedire loro di usare il rmdircomando, che è un modo comune per eliminare le directory, puoi impostare le autorizzazioni allo stesso modo sul suo percorso eseguibile:

sudo chmod 750 /bin/rmdir

Ricorda che anche tu puoi usare questi comandi anche con i diritti sudo.

Per cambiarlo se non ti piace o se si verificano altri problemi, utilizzare 755perchmod

Come sottolineato da @muru, quanto sopra è una soluzione molto grezza e potrebbe persino interrompere i servizi di sistema che non sono in esecuzione sull'account di root . Quindi aggiungo qui un'altra opzione usando ACL (liste di controllo degli accessi) per fare lo stesso e probabilmente molto più sicuro ( buono anche da leggere e puoi saltare la parte abilitante perché ACL è di solito installato su sistemi Ubuntu al giorno d'oggi):

Quindi fare lo stesso come sopra solo per gli utenti che vuoi bloccare sarebbe

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

Sostituisci semplicemente <user-name>con i nomi utente effettivi che desideri impedire l'utilizzo dei file.

Come per chmod, usare setfacl -mper impedire l'esecuzione di utenti specifici rme si rmdirapplica solo a quei comandi forniti dal sistema. Non impedisce loro di eliminare i file e le cartelle in Nautilus o utilizzando altri comandi del terminale.

Spiegazione:

• il -mflag significa modificare i file ACL.
• la prima parte della modifica, uindica l'utente. Può avere i seguenti valori uper l'utente, gper il gruppo e oper tutti gli altri
• la parte centrale <user-name>può inserire il nome utente effettivo o il nome del gruppo in base a ciò che si desidera modificare. Per impostare le modifiche generali lo lasci vuoto.
• la terza parte detiene il tipo di autorizzazioni che si desidera impostare. Qui nell'esempio non vogliamo impostare alcuna autorizzazione, quindi possiamo -anche contenere le seguenti lettere rper le autorizzazioni di lettura, wper le autorizzazioni di scrittura e xper l'esecuzione.

Questa è una risposta molto semplice e impedirà a qualcuno di usare casualmente il comando rm senza fornire una password. Non è una soluzione sicura e dovresti implementare alcuni dei suggerimenti alternativi nelle altre risposte.

Tuttavia, è possibile utilizzare l'alias per modificare il modo in cui si comporta il comando rm. Provare:

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

Ciò che fa è quando qualcuno inserisce il comando rm, esegue il comando sudo -l. Questo comando impone all'utente di inserire la propria password. Se lo fanno bene, elenca i loro privilegi (scartiamo questo output) ed esce con lo stato 0, se lo sbagliano, esiste un errore.

Seguiamo quindi il comando sudo con un "&&", che esce dal seguente comando - in questo caso "rm" solo se il comando precedente esce con lo stato 0 - cioè hanno ottenuto la password corretta.

Per renderlo permanente, includere il comando alias in ~/.bashrc.

Nota che questo è molto facile da sconfiggere (per esempio, potrebbero semplicemente digitare /bin/rm.

A volte non sono i nostri amici, siamo i nostri peggiori nemici

Ho scritto uno script per proteggere con password rmcome richiesto dall'OP, ma ho anche apportato modifiche per impedire la cancellazione accidentale:

• /
• /casa
• /bidone

Modifica: 5 marzo 2017 - Modifica il metodo di controllo se in esecuzione nel terminale.

Crea lo script

Usa gksu gedit /usr/local/bin/rme copia in queste righe:

#!/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

Cambia la password "WE2U" in qualsiasi cosa ti piaccia e salva il file.

Contrassegna il nuovo rmscript come eseguibile

Contrassegna il nuovo rmscript come eseguibile utilizzando:

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

Come funziona

A meno che la password non sia WE2U , la prima volta che si esegue lo script si ottiene "password non valida" e viene visualizzata la chiave di crittografia per la password inserita. Copia e incolla questa chiave di crittografia dal terminale nello script. Quindi commentare la riga con l'eco che ha visualizzato la chiave di crittografia sul terminale.

Perché il percorso /usr/local/binè più in alto nell'elenco rispetto al /binnostro comando rm. Dopo aver ottenuto una password valida, chiama /bin/rmper eseguire la rimozione reale.

Come ha sottolineato Thomas Ward in un'altra risposta, se dovessi fare una, sudo apt-get install ...potresti aver chiesto la password mille volte. Lo script controlla se sudoviene utilizzato e non richiede una password. Inoltre, se rmviene chiamato dall'interno della GUI, non è richiesta alcuna password.

Lo script chiama loggerper registrare ogni volta che è rmstato chiamato manualmente utilizzando il terminale. L'uso del comando è registrato su /var/log/syslog.

Un'altra alternativa sarebbe quella di creare copie di backup di tutti i file importanti in una directory a cui gli utenti non root non hanno accesso. Puoi usarli rsynco unisonsincronizzarli automaticamente, assicurati solo che almeno una directory nel percorso verso la destinazione del backup sia di proprietà di root e modalità 700. Ciò comporterebbe comunque avere due copie di tutti i file. Sarebbe più sicuro creare solo un utente guest da usare per loro, ad eccezione del fatto che è necessario ricordare di bloccare o disconnettersi sempre prima di dare loro il computer o lasciarlo incustodito.

Non la risposta diretta alla domanda che stai cercando, ma:

Se i tuoi amici stanno cancellando i tuoi file usando il rmcomando, allora i tuoi amici sono incompetenti, cretini o sono aspiranti BOFH che stanno cercando di insegnarti a non lasciare le sessioni connesse e incustodite. In tutti i casi, la soluzione è la stessa: non lasciare la sessione registrata e incustodita .

Ciò ha il vantaggio di non dover ricordare di apportare modifiche speciali al sistema ogni volta che si aggiorna o si ottiene un nuovo sistema e impedisce inoltre che gli script e altre cose che si utilizzano che si basano su comandi che si comportano come previsto falliscano in modo imprevedibile.

Ha anche il vantaggio di impedire agli "amici" di passare al passaggio successivo. Vuoi anche "proteggere con password" il mvcomando se decidono di spostare i tuoi file in / dev / null quando scoprono che una semplice rimozione non fa quello che vogliono? Quando sei in un gioco come questo, l'unica mossa vincente è non giocare.

Ho una possibilità simile che avevo pianificato. Sul file server, se la memoria principale delle foto è scrivibile, qualcuno in famiglia (meno tecnico o per caso) potrebbe eliminare qualcosa, trascinare accidentalmente nella gui che sposta la directory o sovrascrivere un originale con una versione modificata anziché rinominare .

Mi sono reso conto che posso proteggerlo da ciò senza rendere le autorizzazioni non scrivibili per tutti gli altri. ZFS crea istantanee periodiche in modo da poter annullare qualsiasi cancellazione o sovrascrittura accidentale. (A differenza di un backup, un'istantanea è leggera e copia su scrittura in modo da non moltiplicare l'utilizzo della memoria.)

ZFS è nativo di FreeBSD. Linux ha btrfs che ha anche istantanee.

Una soluzione molto sciocca per un problema molto sciocco.

Se non si vuole chmod rm, rmdiro mv(per mv filename /dev/null) o l'uso ACL, è possibile creare un utente fittizio con una password, ma nessuno si conosce e alias ogni comando a sudo [user], e poi fare alias per ogni comando che i tuoi amici non sanno . In questo modo, quando i tuoi amici digitano rmil sistema chiederà loro una password (ma indovinare la password errata registrerà il tentativo fallito), e puoi ancora digitare rmaliaso qualunque cosa tu scelga di eliminare effettivamente i file.

Oppure potresti semplicemente creare un account ospite che non ha accesso alla tua home directory.

Se si desidera proteggere rm con password, una soluzione sarebbe quella di creare un wrapper per rm che richiederebbe i privilegi di root e richiedere una password in caso contrario. (NOTA: questo wrapper potrebbe scomparire quando il pacchetto coreutils viene aggiornato o reinstallato.) Inoltre, si noti che questo protegge solo rm, ci sono ancora molti, molti altri modi per eliminare un file.

Apri un terminale e diventa root. Quindi corri sudo mv /bin/rm /bin/rmoldper spostare la vecchia RM in un altro posto.

Ora corri sudo nano /bin/rmper creare un wrapper.

In Nano, digitare quanto segue:

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

Quindi tieni premuto CTRLe premi Xper uscire. Premere Yquando richiesto, quindi premere ENTERper salvare il file.

Infine, dobbiamo dare a questo le autorizzazioni appropriate:

sudo chmod a+x /bin/rm

E il gioco è fatto.