chmod 1,2 e 4, o que exatamente eles fazem?

Question

Eu estava pensando em ter apenas lido, apenas escrever ou somente permissão de execução, e o que isso significa.

Se eu tiver apenas permissão de gravação, isso significa que posso anexar ou substituir o conteúdo do arquivo, mas não ler o conteúdo atual?

Ainda mais confuso: se eu tiver lido apenas, por que não posso simplesmente copiar o arquivo e executá-lo? Existe uma razão pela qual a permissão de leitura não concede permissão de execução automaticamente? Qual é o uso de não dar permissão de execução a alguém, se eles podem apenas copiar e colar o arquivo em outro lugar e executá-lo lá?

E se eles só tiverem permissão de execução, o que isso significa então? A execução de um arquivo não exige que você o veja?

E minha última pergunta: onde é que faz diferença se a permissão de execução é dada? A execução de um arquivo .txt não faz sentido. No Windows há, por exemplo, .exes, .bats e assim por diante. Em sistemas Unix, só conheço o .sh. Existe um certo número de extensões que definem arquivos executáveis? Se agora, como posso identificar um?

    

Answer 1

No UNIX, chmod 1 = execute, read é 4 e write é 2.

Qualquer coisa pode ser chmod'ed 1 e, em seguida, o shell atual tentará executá-lo, você pode digitar seu nome como um comando. Há algum arquivo "mágico" no início do arquivo, se os primeiros caracteres são "#!" (o shebang) então a próxima parte da linha lista o caminho para o executável real a ser executado e quaisquer opções para passar para o shell. O script de texto é passado para esse binário executável para ler o arquivo e executá-lo efetivamente.

Você pediu, não executa a leitura obrigatória, bem, sim, mas isso ficará a critério do programa binário, por exemplo, korn shell, para mostrar o arquivo. Geralmente é como o DRM, é respeitado pelos programas para verificar suas permissões contra o arquivo. Eu configurei rotinas em shell scripts e marquei-as apenas para --x executável e poderia ser executado e basicamente não lido (acho que algumas versões mais antigas do UNIX tinham problemas com isso, assim como permissões especiais em / tmp, mas isso é outra tópico).

Se um script estiver marcado apenas como 4, ou "lido", ele lhe concederá permissão para enviar o arquivo para o seu terminal. Sim, você poderia executá-lo dependendo de como você passou as linhas para um interpretador de shell, muitos shells têm uma opção de linha de comando para dizer a ele para ler linhas de um determinado arquivo e executá-las como se fosse um script.

E para o seu último caso, o chmod 2 é permissão de gravação. Se você conceder apenas isso, só poderá acrescentar ou destruir o conteúdo do arquivo. Você não pode destruir / unlink / remover o arquivo com base nas permissões do arquivo, a linha que controla se o arquivo existe ou não está dentro do diretório (que eu também gosto de considerar como um arquivo).

Eu teria que argumentar que o chmod 2 não é muito útil em um arquivo, mas em um diretório você pode criar uma espécie de "cofre" para outras pessoas enviarem arquivos para você, geralmente alunos de uma turma, e você espera que eles não sobrescrevam os nomes de outros estudantes.

Deve haver alguma ajuda nas páginas de manual "man chmod", e esperamos que você tenha seu próprio sistema UNIX para testar as coisas em seu próprio diretório pessoal. Muitos dos casos mais estranhos, como o de execução, requerem apenas que outro usuário ou amigo mostre o resultado das várias permissões.

    

Answer 2

O que isso significa

Os valores octal de permissão de segurança permitem que as permissões correlatas sejam definidas explicitamente em um objeto. Você pode ficar explícito com essas permissões definidas em um objeto com chmod . Veja a tabela abaixo mencionada para mais detalhes sobre isso também.

O que eu tenho

Por exemplo, se você quiser permitir que alguém execute um arquivo para executar alguma lógica e por Shebang sem ser capaz de ler o conteúdo ou ver a lógica, então essa flexibilidade está lá.

Definir por sua própria necessidade

Você define as permissões de segurança de acordo com suas próprias necessidades individuais, portanto, se alguma configuração de segurança não fizer sentido para você, você simplesmente não precisará usá-la como tal.

Numerical Permissions

The chmod numerical format accepts up to four octal digits. The three rightmost digits refer to permissions for the file owner, the group, and other users, respectively. The optional leading digit, when 4 digits are given, specifies the special setuid, setgid, and sticky flags.

Each digit of the three rightmost digits represent a binary value, which it's bits control the read, write and execute respectively, where 1 means allow and 0 means don't. This is similar to the octal notation, but represented in decimal numbers.

# Permission              rwx Binary
7 read, write and execute rwx 111
6 read and write          rw- 110
5 read and execute        r-x 101
4 read only               r-- 100
3 write and execute       -wx 011
2 write only              -w- 010
1 execute only            --x 001
0 none                    --- 000

For example, 754 would allow:

• read, write, and execute for the OWNER, as the binary value of 7 is 111, meaning all bits are on.

• read and execute for the GROUP, as the binary value of 5 is 101, meaning read and execute are on but write is off.

• read only for EVERYONE ELSE, as the binary value of 4 is 100, meaning that only read is on.

    

Answer 3

Como observado por outros, as permissões de arquivo são um pouco de máscara. O sistema não sai do seu caminho para evitar o uso de combinações estranhas ou inúteis: inútil não significa prejudicial.

If I have write permission only, does that mean I can append to, or replace the contents of the file, but not read the current contents?

Sim.

If I have read only, why can't I just copy the file and execute it then?

Você pode, com exceções. Copiar um arquivo "privilegiado" (um que tenha bits setuid / setgid ou recursos de arquivo Linux) não copiará essas propriedades. Você também precisa de um local para copiá-lo e é possível ter um sistema no qual a partição / home não permita a execução de arquivos a partir dele.

O mesmo pode ser feito sem copiar, invocando manualmente o interpretador correspondente. Por exemplo, você pode executar scripts shell via sh /path/to/script , mesmo que não sejam executáveis. Binários no Linux também possuem um interpretador, /lib/ld-linux.so .

And if they have only execute permission, what does that mean then? Doesn't executing a file require you to see it?

Ele faz - mas isso é verificado após o bit setuid é processado. Se você estiver executando um programa setuid, ele terá os privilégios do proprietário, portanto, somente o proprietário precisa de + r.

Para diretórios, o + x tem um significado diferente (ele permite que você percorra a pasta, ou seja, acesse itens dentro dela). Se você sabe o nome exato de um arquivo dentro, você pode acessá-lo com apenas + x, não + r, no diretório.

Where does it make a difference if execute permission is given? executing a .txt file doesn't make sense. On Windows there are for example .exes, .bats, and so on. On Unix systems, I only know of .sh. Is there a certain number of extensions that define executable files?

A capacidade de execução não é definida pelo nome do arquivo, mas pelo seu conteúdo. (Afinal, você está executando o conteúdo, não o nome.)

Um arquivo pode ser executável quando o kernel sabe como carregá-lo como um. O kernel do Linux entende arquivos binários ELF, assim como arquivos "script" com o cabeçalho #! como primeira linha. (O mesmo acontece com a maioria dos outros sistemas operacionais semelhantes ao Unix.) Portanto, faz sentido usar + x nesses dois tipos de arquivos apenas.

Por exemplo, se um arquivo de script começar com #!/bin/sh , a execução fará o mesmo que a execução manual de /bin/sh myscript.sh . O mesmo pode ser aplicado a Python ou Perl ou Ruby ou TCL ou C # ou Node / JavaScript ou qualquer outro idioma. (Mais uma vez, observe que o sufixo do nome do arquivo não tem relevância - apenas o cabeçalho mágico faz isso.)

A vantagem é que seu sistema pode ter comandos escritos em vários idiomas diferentes, e você pode usá-los sem ter que se preocupar com qual interpretador cada comando usa.

O Windows está em uma situação similar . Ele também tem o mesmo bit de permissão 'executável' e, embora a interface gráfica queira o sufixo .exe em nomes de arquivos, o kernel real só se preocupa com o conteúdo do arquivo. (O Windows usa executáveis binários MZ / PE e não suporta #! Para scripts.)