Como posso configurar uma senha para o comando 'rm'?

29

Meus amigos continuam excluindo meus arquivos usando o terminal. Então, por favor, me ajude explicando como criar uma senha para o comando rm .

    
por aswin 27.12.2016 / 13:25

10 respostas

46

Não existe uma maneira fácil de configurar essa senha no comando rm , não sem muito hacking de código que provavelmente quebrará coisas como apt-get instalando pacotes e removendo arquivos, e fazendo com que você tenha que digitar a senha mil vezes, ou potencialmente atrapalhando o acesso ao comando para pessoas que precisariam dele (como você, para deletar seus próprios arquivos). Você pode fazer isso com várias contas de usuário e vários conjuntos de permissões de acesso e restringir o acesso a diferentes seções de dados, como seu diretório inicial, para que eles não consigam acessá-las.

(A outra opção é contas de usuário individuais para cada usuário e, em seguida, as Listas de Controle de Acesso, conforme detalhado na outra resposta que foi postado por Videonauth )

Aqui está o problema central - você está permitindo que seus amigos usem seu sistema. Isso tem numerosas implicações de segurança - o conceito de "qualquer pessoa com acesso físico à caixa será capaz de controlar o sistema e realizar quaisquer tarefas" é um Mantra de Segurança de TI e é por isso que você não "compartilha" o acesso a sistemas físicos, exceto com pessoal autorizado e confiável.

A única maneira verdadeiramente sã de fazer isso é não dar aos seus amigos acesso ao seu computador, e dar a eles um 'sistema convidado' dedicado 'que eles possam use, você não se importa muito com os arquivos. Essa é a maneira mais "segura" de manter seus arquivos seguros.

É claro que, se isso não for uma opção, sua única opção realmente segura é configurar várias contas de usuário, uma para cada usuário, com diferentes pastas base, e não permitir acesso ao seu diretório pessoal ou acesso a qualquer diretórios pessoais de outros usuários. E mantenha tudo o que você não quer que eles toquem em seu diretório pessoal e não dê a eles sudo access, a root password ou compartilhe sua senha com eles.

Isto é como você faria isso:

Digamos que meu nome seja "Foo" e quero que o usuário "Bar", um amigo, use meu sistema, mas não acesse meus arquivos. O primeiro passo é negar o acesso a qualquer pessoa, exceto eu, ao meu diretório pessoal. Isso é para permitir que outros usuários não excluam seus arquivos, mas também para impedir que outros usuários procurem em seu diretório pessoal e ver que tipos de coisas você tem em seu diretório pessoal:

chmod 750 /home/Foo

O segundo passo é criar uma conta de usuário para "Bar" (não digite o que está entre parênteses abaixo, é apenas para fins informativos). Dessa forma, podemos garantir que ele tenha seu próprio conjunto separado de direitos de acesso:

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)

O terceiro passo é então restringir o seu diretório home também para que ninguém possa entrar em seus arquivos também. Isso é apenas tornar as coisas iguais.

sudo chmod 750 /home/Bar

Lave as mãos, lave-as bem e repita essas etapas para quantos usuários você tiver no sistema. Eles não poderão acessar seus arquivos e, como você não concederá privilégios de administrador, eles não poderão excluir seus arquivos sem tentar sudo , pois você não permite isso, eles não pode tocar nas suas coisas. E eles não poderão ver seus arquivos também, sem se tornarem superusuários, o que não acontecerá aqui.

SEMPRE LEMBRE-SE ISTO: Ao conceder a alguém acesso físico à máquina ou acesso em geral, você colocará seus arquivos e dados em risco. Esse é um fato amplamente aceito no mundo de segurança de TI e que continua sendo verdadeiro. Dar a seus amigos acesso ao seu computador sempre colocará seus dados em risco, portanto, forneça a eles seu próprio sistema para mexer com eles ou simplesmente não dê a eles acesso à sua máquina.

Apenas uma nota sobre criptografia de disco

Embora a criptografia de disco funcione bem para proteger seus dados de terceiros, há limitações.

  1. Se o sistema estiver ligado, o disco já está descriptografado, por isso você está em risco.
  2. Alguns sistemas têm abordagens de criptografia de disco quebradas . Por exemplo, alguns sistemas Acer usam sua senha para autorizar somente a criptografia / descriptografia e usar senhas codificadas ou usar criptografia fraca que é facilmente quebrada.
  3. Existem sempre métodos para invadir as 'chaves', ou tentar extraí-los da memória logo após um sistema ser desligado, mas antes que os dados da RAM sejam 'eliminados' ou deteriorados. (Eu não irei em profundidade sobre estes, mas estes riscos fazem existem).
  4. O acesso físico à máquina, quer o sistema esteja criptografado ou não, sempre colocará seus dados em risco. Não forneça acesso físico (ou acesso remoto à rede) a pessoas que você não deseja potencialmente dar acesso total ao seu sistema.

Embora a Criptografia de Disco não resolva esses problemas, ela coloca camadas extras de dores de cabeça para um agente de ameaça.Alguém que é um cara mau pode desistir se é criptografado, ou eles podem te torturar (fila obrigatória tira cômica do XKCD Security ).

Portanto, se o seu sistema estiver criptografado, mas você permitir que outros usuários o utilizem, eles terão uma senha para descriptografar ou se você deixar o laptop descriptografado para que eles possam acessar o SSH ou ter acesso físico. Em ambos os casos, é ruim.

Dito isto, se o seu sistema não estiver criptografado, essa seção não terá relevância para você.

    
por Thomas Ward 27.12.2016 / 13:40
19

Isso pode não ser realmente sobre o comando rm , pois existem maneiras fáceis de excluir arquivos sem usá-lo . Se o problema é que seus amigos estão, inadvertidamente, usando indevidamente o comando rm , as soluções que restringem o uso desse comando especificamente ou fazem com que ele funcione de maneira diferente podem ser de alguma ajuda. Por outro lado, se o problema é que seus amigos estão deliberadamente tratando seus dados de uma forma que você não deseja, então você precisa implementar medidas de segurança , e nenhuma solução que se concentre no comando rm (ou qualquer conjunto discreto de comandos) irá mantê-lo seguro.

Você precisa controlar o acesso ou apenas evitar erros honestos?

Supondo que seus amigos saibam que você não quer que eles excluam seus arquivos, há duas possibilidades:

  1. Eles podem estar fazendo isso de propósito. Nesse cenário, seus amigos estão deliberadamente excluindo seus arquivos e você não pode confiar neles para tentar obedecer com seus desejos sobre como eles tratam seus dados quando eles usam seu computador. A única solução para este problema é para usar uma medida efetiva de segurança efetiva , como Thomas Ward explicou em detalhes . Muitas vezes, a melhor medida é evitar que eles usem o computador. Mas fazê-los usar suas próprias contas de usuário pode fornecer alguma proteção.

  2. Eles podem estar fazendo isso por engano. Nesse cenário, seus amigos são extremamente propensos a acidentes e continuam executando rm dos comandos que desejam que não tivessem. Eles querem tratar você e seus dados com respeito, mas são muito ruins em fazer isso na prática, porque eles continuam executando o comando errado, excluindo o arquivo errado ... ou algo parecido. Embora seja bom acreditar que isso é o que está acontecendo, aconselho-o a não presumir que as pessoas que continuam excluindo seus dados depois de mandá-las parar estão operando sem má vontade.

    Além disso, mesmo que suas intenções sejam boas, dar a elas contas de usuário separadas ainda é a maneira mais fácil de evitar que eles excluam seus arquivos, além de não permitir que eles usem seu computador.

Se a situação for realmente a # 2 - seus amigos não tentar excluir seus arquivos, mas precisarem de ajuda para não acidentalmente excluí-los, e a única maneira como eles já acidentalmente excluí-los é através do inadvertido uso indevido de um pequeno número de comandos (como rm ) que eles têm problemas específicos usando corretamente - então as técnicas da resposta do Videonauth podem ser de alguma utilidade. Mas você deve entender que elas não são medidas de segurança, porque o comando rm é apenas uma das muitas maneiras fáceis de excluir arquivos . Veja abaixo para detalhes.

Eu recomendo que você se pergunte: "A minha situação é basicamente a mesma que se eu, em vez das outras pessoas que usam o meu computador, fosse a pessoa que usava rm incorretamente?"

Se a resposta for não , então, isso é uma questão de segurança da informação, e você precisa impedir que seus amigos usem sua conta de usuário. Se a resposta for yes , então você pode usar as mesmas abordagens que você usaria se você fosse a pessoa usando indevidamente rm :

  • Educação. Seus amigos precisam saber o que estão fazendo e como evitá-lo.
  • Mudanças de interface. Sem eliminar a capacidade real de excluir arquivos (o que requer contas de usuário separadas), você pode tornar mais difícil acidentalmente excluir arquivos, tornando-a tão simples co_de% por si só, sem nenhuma ação adicional, não excluirá imediatamente rm file . A resposta da Videonauth oferece uma abordagem para isso. Nesta resposta, apresento outro.

Mas mesmo que seus amigos não estejam tentando fazer nada de errado, você ainda deve considerar que eles usem suas próprias contas de usuário separadas . Isso ainda resolverá o problema - as mesmas medidas de segurança que protegem os dados contra a destruição deliberada também o protegerão da destruição não intencional. Mesmo sem intenções maliciosas, se alguém continuar fazendo algo que você não quer que eles façam, então você não pode confiar neles para evitar fazer aquilo.

Tornar file pronta antes da exclusão pode ajudar a evitar alguns erros.

Para ajudar as pessoas a evitar acidentalmente a exclusão de arquivos com rm , você pode criar rm a alias do shell que, na verdade, executa rm . Passar o sinal rm -i para -i faz com que ele avise o usuário antes de excluir cada arquivo (veja rm ).

Você pode fazer isso (para sua conta de usuário) adicionando man rm ao seu arquivo alias rm='rm -i' ou .bash_aliases . Veja esta questão e aquele para detalhes. Isso entrará em vigor para as suas conchas de bash recém-abertas.

Isso fornece nenhuma segurança real e não é infalível na prevenção de erros, porque:

  • Eles podem optar por prosseguir com a exclusão, quando solicitado.
  • Eles podem ignorar o alias de várias maneiras, inclusive executando .bashrc ou unaliasing ( /bin/rm ).
  • Existem muitas situações em que a expansão de alias não ocorre e, nessas situações, unalias rm não será executado com rm .
  • Eles ainda podem excluir arquivos usando qualquer uma das técnicas para fazer isso que não exigem -i (como é o caso com A abordagem do Videonauth - veja abaixo).
  • Eles ainda podem danificar dados sem excluir nenhum arquivo, por exemplo, sobrescrevendo-os ou alterando seu conteúdo (como também acontece com a abordagem da Videonauth).

Mas se você não precisa de segurança real (veja acima), então este pode ser o caminho a percorrer. Em comparação com a abordagem de impedir que seus amigos usem o comando rm fornecido pelo sistema:

  • Aliasing rm to rm é menos eficaz na prevenção de erros - até que eles passem a usar outra técnica para remover arquivos. Nesse ponto, impedi-los de usar rm -i será totalmente ineficaz, mesmo se eles não estiverem tentando fazer algo errado, já que presumivelmente eles usarão rm (ou qualquer um dos inúmeros outros comandos que removem um arquivo) com igual irreflexão.

  • Por outro lado, como a expansão de alias só ocorre em algumas situações - grosso modo, uso interativo comum do shell - seus amigos podem pensar que eles serão solicitados quando não forem realmente solicitados (porque o comando está em um script, por exemplo, ou emitido de um shell diferente). O jeito da Videonauth não tem esse problema, que é uma vantagem objetiva desse método sobre unlink .

  • Quando um script é executado, a menos que seja escrito deliberadamente para usar aliases, seus aliases não são expandidos nele. Isso significa que é muito improvável que o aliasing alias rm='rm -i' to rm quebre nada. Esta é uma vantagem objetiva de rm -i .

alias rm='rm -i' não pode fazer nada que outro programa perfeitamente normal não possa fazer.

Não há nada de especial sobre rm . É uma maneira conveniente e autodocumentada de remover arquivos, portanto, restringir o acesso a ele pode quebrar vários scripts que dependem dele. Mas está longe de ser a única maneira de excluir arquivos - é apenas um programa comum.

Alguns comandos executam alguma tarefa que um usuário limitado (não root ) não pode executar sem executá-los. Por exemplo, rm permite que você execute programas como outro usuário, depois de verificar se está autorizado a fazê-lo. sudo edita o banco de dados onde as senhas dos usuários são armazenadas, mas apenas permite você muda sua própria senha (a menos que você seja root, caso em que você pode mudar a senha de qualquer pessoa).

passwd e /usr/bin/sudo podem fazer isso porque têm o conjunto de bit setuid , conforme mostrado pelo /usr/bin/passwd que aparece na coluna mais à esquerda quando você executa s :

[email protected]:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
[email protected]:~$ 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

Observe que ls -l não tem /bin/rm : suas permissões são s , enquanto -rwxr-xr-x e /usr/bin/passwd têm /usr/bin/so . Isso faz com que, independentemente de quem executa -rwsr-xr-x ou passwd , ele seja executado como usuário root, já que root é o proprietário do executável. (Há também um bit setgid, que, quando definido, faz com que os executáveis sejam executados com a identidade do grupo do proprietário do grupo, e não do chamador.)

Exceto para quaisquer vulnerabilidades de segurança que ainda não tenham sido descobertas (ou que foram descobertas, mas ainda não foram corrigidas), sudo e sudo são seguras porque esses utilitários são escritos com muito cuidado para que eles possam faça coisas que o interlocutor deve fazer.

passwd não funciona dessa maneira. Não é setuid porque não precisa ser. Permissões do diretório (e ocasionalmente permissões de arquivo ) controlam quais arquivos um usuário pode excluir e não precisam se tornar root para fazer isso.Apenas para ficar bem claro, por favor, nunca defina o bit setuid em /bin/rm . As implicações de segurança seriam desastrosas, desde então, não importa quem executa rm , é como se o root rodasse! (Utilitários como rm e sudo verificam quem os está realmente executando e verificam se algo é permitido antes de fazê-lo; passwd não faz isso.)

Verificar se o bit setuid (ou setgid) está definido em um executável irá dizer se restringir quem pode executá-lo é uma chance de melhorar a segurança. Executáveis que não são setuid (ou setgid) não possuem nenhum status especial, e qualquer um pode simplesmente copiá-los e executar a cópia, trazer sua própria cópia de outra máquina, escrever um script ou programa que faça a mesma coisa ou usar outro programa para fazer isso.

Excluindo arquivos sem rm

A maneira óbvia de excluir um arquivo sem rm no Ubuntu é navegar até seu local no navegador de arquivos gráficos (Nautilus, se você estiver usando o Unity ou o GNOME Shell) e excluir o arquivo. Há também vários comandos que podem ser usados para excluir um arquivo de um terminal, sem nunca usar rm .

Por exemplo, para remover um arquivo chamado rm no diretório atual, os seguintes comandos, que funcionam de maneira simples no Ubuntu e não requerem acesso a foo.txt , conseguirão isso. (Só para ter certeza, eu os testei em um sistema mínimo 16.04 instalado apenas com os utilitários padrão do sistema, após a exclusão rm .)

  • /bin/rm
  • unlink foo.txt
  • busybox rm foo.txt
  • perl -e 'unlink("foo.txt")' ( python3 -c 'import os; os.remove("foo.txt")' em vez de python em versões mais antigas)

Essa lista, é claro, está longe de ser completa. Nenhuma lista completa de tais comandos é possível. Evitar a exclusão de arquivos é uma das coisas que as contas de usuário separadas e as permissões de arquivo e diretório existem para alcançar. Eles funcionam muito bem para evitar isso. Por outro lado, alterar o comando python3 (para exigir uma senha ou de qualquer outra forma) ou restringir o acesso a rm não o impede.

    
por Eliah Kagan 27.12.2016 / 20:51
16

Você pode alterar as permissões no comando /bin/rm através da seguinte linha, o que impedirá que ele seja executado sem acesso ao sudo:

sudo chmod 750 /bin/rm

Isso impede especificamente que eles usem o comando rm fornecido pelo sistema. Você deve estar ciente de que isso não impede que eles excluam arquivos de outras maneiras.

Para também impedi-los de usar o comando%% co_de, que é uma forma comum de apagar diretórios, você pode definir as permissões da mesma forma em seu caminho executável:

sudo chmod 750 /bin/rmdir

Lembre também que você também pode usar esses comandos com os direitos sudo.

Para alterá-lo de volta, caso você não goste ou use outros problemas, use rmdir para 755

Como @muru apontou o acima é uma solução muito bruto e pode até quebrar serviços do sistema que não estão em execução no root conta. Portanto, eu acrescentar aqui outra opção usando (listas de controle de acesso) ACL para fazer o mesmo e, provavelmente, muito mais seguro ( bom ler para além e você pode pular a parte de habilitação porque a ACL é normalmente instalada nos sistemas Ubuntu hoje em dia):

Então, para fazer o mesmo que acima apenas para os usuários que você deseja bloquear seria

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

Apenas substitua chmod pelos nomes de usuário reais que você deseja impedir o uso dos arquivos.

Tal como acontece com <user-name> , usando chmod para impedir que usuários específicos de correr setfacl -m e rm aplica-se apenas aos comandos fornecidos pelo sistema. Ele não os impede de excluir seus arquivos e pastas no Nautilus ou usando outros comandos do terminal.

Explicação:

  • o sinal rmdir significa modificar a ACL dos arquivos.
  • a primeira parte da alteração, o -m significa usuário. Pode ter os seguintes valores u para usuário, u para grupo e g para todos os outros
  • a parte do meio o pode holt o nome do usuário real ou nome do grupo de acordo com o que você deseja alterar. Para definir alterações gerais, você a deixa vazia.
  • a terceira parte contém o tipo de permissão que você deseja definir. Aqui no exemplo que queremos definir nenhuma permissão em tudo isso, colocar <user-name> , pode também conter os seguintes letras - para permissões de leitura, r para permissões de gravação e w para execução.
por Videonauth 27.12.2016 / 13:40
8

Esta é uma resposta muito simples e irá parar alguém casualmente usando o comando rm sem dar uma senha. Não é uma solução segura e você deve implantar algumas das sugestões alternativas nas outras respostas.

No entanto, você pode usar o alias para alterar a maneira como o comando rm se comporta. Experimente:

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

O que isto faz é quando alguém insere o comando rm, ele executa o comando sudo -l. Este comando força o usuário a digitar sua senha. Se eles acertarem, ele lista seus privilégios (nós descartamos esta saída) e sai com o status 0, se eles errarem, existe com um erro.

Em seguida, seguimos o comando sudo com um "& amp; & amp;", que sai do seguinte comando - neste caso, "rm" apenas se o comando anterior sair com o status 0 - ou seja, eles obtiveram a senha correta. / p>

Para tornar isso permanente, inclua o comando alias em ~/.bashrc .

Note que isto é facilmente derrotado (por exemplo, eles poderiam simplesmente digitar /bin/rm .

    
por Nick Sillito 27.12.2016 / 19:05
5

Às vezes não são nossos amigos, somos nossos piores inimigos

Eu escrevi um script para proteger com senha rm , como o OP solicitado, mas também coloquei edições para evitar que você exclua acidentalmente:

  • /
  • / home
  • / bin

Editar: 5 de março de 2017 - Alterar o método de verificar se está sendo executado no terminal.

Crie o script

Use gksu gedit /usr/local/bin/rm e copie nas seguintes linhas:

#!/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 [email protected]' 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 "[email protected]"

exit 0

Altere a senha "WE2U" para o que quiser e salve o arquivo.

Marcar o novo script rm como executável

Marcar o novo script rm como executável usando:

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

Como funciona

A menos que a senha seja WE2U , a primeira vez que você executar o script, receberá "senha inválida" e a chave de criptografia da senha digitada será exibida. Copie e cole essa chave de criptografia do terminal no script. Em seguida, comente a linha com o eco que exibiu a chave de criptografia no terminal.

Como o caminho /usr/local/bin é maior na lista do que /bin , nosso comando rm é chamado. Depois de obter uma senha válida, chama /bin/rm para fazer a remoção real.

Como Thomas Ward apontou em outra resposta, se você fosse fazer um sudo apt-get install ... você poderia ser solicitado a senha mil vezes. O script verifica se sudo é usado e não solicita uma senha. Além disso, se rm for chamado de dentro do aplicativo da GUI, nenhuma senha será necessária.

O script chama logger para gravar sempre que rm foi chamado manualmente usando o terminal. O uso de comandos é registrado em /var/log/syslog .

    
por WinEunuuchs2Unix 30.12.2016 / 03:32
3

Outra alternativa seria criar cópias de backup de todos os arquivos importantes em um diretório ao qual os usuários não-root não têm acesso. Você poderia usar rsync ou unison para sincronizá-los automaticamente, apenas certifique-se de que pelo menos um diretório no caminho para o destino de backup seja de propriedade root e modo 700. Isso resultaria em ter duas cópias de todos os arquivos. Seria mais seguro apenas criar um usuário convidado para eles usarem, exceto pelo fato de você precisar se lembrar de sempre bloquear ou desconectar-se antes de fornecer o computador ou deixá-lo sozinho.

    
por Random832 27.12.2016 / 15:38
2

Não é a resposta direta à pergunta que você está procurando, mas:

Se seus amigos estiverem excluindo seus arquivos usando o comando rm , seus amigos serão incompetentes, idiotas ou BOFH wannabes que estão tentando ensinar você a não deixar suas sessões conectadas e desacompanhadas. Em todos os casos, a solução é a mesma: não deixe sua sessão conectada e sem supervisão .

Isso tem a vantagem de não precisar se lembrar de fazer alterações especiais no sistema sempre que você atualiza ou obtém um novo sistema, e também impede que scripts e outras coisas que você usa dependam de falhas inesperadas de acordo com os comandos.

Ele também tem a vantagem de impedir que "amigos" passem para a próxima etapa. Você também vai querer "proteger com senha" o comando mv se eles decidirem mover seus arquivos para / dev / null quando descobrirem que uma remoção simples não faz o que eles querem? Quando você está em um jogo como este, o único movimento vencedor é não jogar.

    
por Rob Moir 29.12.2016 / 16:32
1

Eu tenho uma possibilidade semelhante que planejei. No servidor de arquivos, se o armazenamento principal das fotos for gravável, alguém na família (menos técnico ou por acidente) pode excluir algo, arrastar acidentalmente a GUI que move o diretório ou substituir um original por uma versão editada, em vez de renomear. .

Percebi que posso proteger contra isso sem tornar as permissões não graváveis para todos os outros. O ZFS faz instantâneos periódicos para que qualquer exclusão ou substituição acidental possa ser revertida. (Diferentemente de um backup, um instantâneo é leve e copia com gravação, por isso não multiplica seu uso de armazenamento.)

O ZFS é nativo do FreeBSD. O Linux tem o btrfs que também possui instantâneos.

    
por JDługosz 28.12.2016 / 08:08
0

Uma solução muito boba para um problema muito bobo.

Se você não quiser chmod rm , rmdir ou mv (para mv filename /dev/null ) ou usar ACLs, poderá criar um usuário fictício com uma senha, mas você sabe e alias cada comando para sudo [user] e, em seguida, fazer aliases para cada comando que seus amigos não sabem. Dessa forma, quando seus amigos digitarem rm , o sistema solicitará uma senha (mas a senha errada será registrada na tentativa malsucedida), e você poderá digitar apenas rmalias ou o que você escolher para realmente excluir arquivos. / p>

Ou você pode criar uma conta de convidado que não tenha acesso ao seu diretório pessoal.

    
por Andy 29.12.2016 / 17:26
0

Se você quiser proteger com senha o rm, uma solução seria criar um wrapper para rm que exigiria privilégios de root e solicitar uma senha de outra forma. (NOTA: Este wrapper pode sumir quando o pacote coreutils é atualizado ou reinstalado.) Além disso, observe que isso apenas protege o rm, ainda existem muitas, muitas outras maneiras de excluir um arquivo.

Abra um terminal e torne-se root. Em seguida, execute sudo mv /bin/rm /bin/rmold para mover o antigo rm para outro lugar.

Agora, execute sudo nano /bin/rm para criar um wrapper.

No Nano, digite o seguinte:

#!/bin/bash
/bin/rmold "[email protected]"
exit "$?"

Em seguida, segure CTRL e pressione X para sair. Pressione Y quando solicitado e, em seguida, pressione ENTER para salvar o arquivo.

Por fim, precisamos conceder a isso as permissões adequadas:

sudo chmod a+x /bin/rm

E lá vai você.

    
por InitializeSahib 27.12.2016 / 22:34