Perguntas[permissions](unix)

Estou usando o Ubuntu 24.10. Meu /mediadiretório (o ponto de montagem usual para HDD externo) tem as seguintes permissões:

$ ls -l / | grep media
drwxr-xr-x   4 root root       4096 mag 16  2024 media

O proprietário é root, mas tem permissões para executar (ou seja, entrar) no diretório. Como usuário normal, posso fazer:

$ ls /media/
mark  root

se eu executar o Audacity como usuário normal (instalado a partir de snap) e tentar abrir um arquivo de áudio, ele se recusa a entrar no /mediadiretório:

Erro ao abrir o diretório /media: Permissão negada

Tentei:

sudo chmod -R a+rxw /media/

Mas nada mudou. O que devo fazer para permitir que o Audacity entre neste diretório?

Para tornar um script de shell executável, parece haver três opções:

• Opção 1:chmod +x script.sh
• Opção 2:chmod a+x script.sh
• Opção 3:chmod a+rx script.sh

Aqui estão duas perguntas.

Q1. O que realmente significa que a primeira e a segunda opções concedem permissão para executar, mas não concedem permissão para ler? Como isso é possível na vida real?

Q2. Qual dessas opções é recomendada para um caso geral? Ou, para tornar essa pergunta menos pessoal, quais são os prós e os contras de cada opção?

Ouvi dizer que chmod 777é uma ideia horrível. No entanto, ninguém mais vai usar meu sistema (e esse é um cenário bem comum para muitos sistemas *nix). Por que eu não deveria permitir tudo?

Existe um sistema de arquivos que respeita esses dois requisitos?

1. suporta permissões de arquivo padrão Linux
2. é reconhecido nativamente pelo Windows

Gostaria de usá-lo para formatar um pendrive externo USB que uso principalmente para coisas do Linux, mas também gostaria de acessar de uma máquina Windows.

Uma solução simples é simplesmente ler o conteúdo do pendrive de uma VM Linux no host Windows, mas fiquei curioso para saber se esse sistema de arquivos existe.

Tenho uma situação em que um usuário (" minknow ") está criando arquivos/diretórios e quero que outro usuário (o meu, " nano2 ") tenha acesso rwx (total) a eles sem precisar alterar as permissões com sudo toda vez que um novo diretório for criado.

Então, tentei resolver esse problema simplesmente adicionando o grupo primário do usuário minknow como um grupo secundário ao usuário nano2 usando o comando abaixo:

sudo usermod -a -G minknow nano2 Isso deve adicionar o grupo minknow ao usuário nano2 .

Em seguida, verifiquei os grupos usando o comando id -Gn para verificar a adição do grupo:

nano2@nano2:/var/lib/minknow/data/P2_WGS_v3/23RKG025670$ id -Gn nano2
nano2 adm cdrom sudo dip plugdev lpadmin sambashare minknow docker

Mas não funciona como pretendido. O usuário nano2 não tem permissões como parte do grupo minknow - Eu tenho um diretório criado pelo usuário minknow com as seguintes permissões (da saída "ll"):

drwxrwxr-x  3 minknow minknow 4096 Jan  8 10:46 23RKG025670/

O usuário nano2 não consegue criar nenhum arquivo dentro desse diretório.

Agora, eu também verifiquei o comando id sem especificar o nome de usuário. Pelo meu entendimento, isso deveria simplesmente gerar meu id e grupos, mas a saída é um pouco diferente da acima:

nano2@nano2:/var/lib/minknow/data/P2_WGS_v3/23RKG025670$ id -Gn
nano2 adm cdrom sudo dip plugdev lpadmin lxd sambashare

Dois grupos estão faltando, incluindo o grupo dos minknow .

Verifiquei que meu usuário é de fato nano2 com o comando whoami .

O que está acontecendo aqui? Qual é a diferença entre "id" e "id {my_own_username}"? E por que minha tentativa de conceder permissões de grupos para nano2 falha?

Muito obrigado desde já!

Em um sistema CoreOS relativamente novo e simples, tentando executar o seguinte comando:

podman run --rm docker.io/curlimages/curl -v host.containers.internal:2040

Resulta no seguinte erro:

{"msg":"exec container process `/entrypoint.sh`: Permission denied","level":"error","time":"2024-11-22T22:12:56.046889Z"}

Para o qual estou completamente perdido. Eu tentei o seguinte:

• sudo setenforce 0para desabilitar o SELinux temporariamente, o que não alterou o erro recebido.

• Adicionado o --userns=keep-idsinalizador ao comando, o que também não alterou os resultados.

POR EXEMPLO:

podman run --userns=keep-id --rm docker.io/curlimages/curl -v host.containers.internal:2040

• Para outros contêineres podman mais complexos, tentei definir o :zsinalizador para montagens de volume, mas sem sucesso.

Deve haver algo que estou fazendo errado no meu sistema. A única parte anormal do meu sistema é que tenho podman e docker instalados na mesma máquina por questões de compatibilidade, mas meu entendimento é que isso não deve ser um conflito.

Tenho um compartilhamento NFS configurado no armazenamento HP 3PAR 8200 com os seguintes detalhes:
Nome do compartilhamento NFS :Thunder

O compartilhamento NFS foi montado com sucesso na minha máquina Linux em /Thunder:
Comando de montagem :mount.nfs 192.168.x.x:/VFS_FPG/VFS/VFS/Thunder /Thunder

Eu também tenho um servidor RedHat IPA onde criei um grupo chamado thunder e adicionei os membros test, test1 e test2 neste grupo. Eu atribuí as seguintes permissões ao diretório montado

chown -R root:thunder /Thunder  
chmod -R 775 /Thunder

Entretanto, quando alterno para o teste de usuário e tento criar um arquivo ou diretório em /Thunder, aparece o erro "permissão negada" .

O que eu tentei:

• Verificou se o usuário test é um membro do grupo thunder. Verificou a propriedade e as permissões em /Thunder(mostra como root:thundercom 775permissões).

Conforme mostrado abaixo, no meu sistema Ubuntu, carloo diretório tem a permissão sticky bit definida. Ele contém o arquivo file1de propriedade do usuário lab.

lab@ubuntu:~$ ll | grep carlo
drwxrwxr-t  2 ubuntu ubuntu  4096 Oct 31 08:09 carlo/

lab@ubuntu:~$ ll /home/ubuntu/carlo/file1 
-rw-rw-r-- 1 lab ubuntu 0 Oct 31 08:09 /home/ubuntu/carlo/file1
lab@ubuntu:~$

Como você pode ver, o usuário labé o proprietário file1, mas não pode renomear ou excluir o arquivo.

lab@ubuntu:~$ mv /home/ubuntu/carlo/file1 /home/ubuntu/carlo/file2
mv: cannot move '/home/ubuntu/carlo/file1' to '/home/ubuntu/carlo/file2': Permission denied

lab@ubuntu:~$ rm /home/ubuntu/carlo/file1
rm: cannot remove '/home/ubuntu/carlo/file1': Permission denied
lab@ubuntu:~$

Esse é um comportamento esperado?

Estou tentando aprender um pouco mais sobre segurança no Linux e estou com dificuldades para entender a diferença em permissões e acesso para um aplicativo instalado via sudo, em vez de executar um aplicativo via sudo. Tenho algumas perguntas sobre isso:

1. Ao instalar um aplicativo usando sudo, isso dá ao aplicativo permissão total para fazer o que quiser no meu sistema? Ou há restrições sobre o que isso permite?
2. Se um aplicativo foi instalado usando sudo, há alguma diferença em acesso/permissões se o aplicativo for executado com/sem o uso do comando sudo? (por exemplo, sudo pluma)
3. Se um programa não foi instalado usando sudo, há diferença nas permissões se ele for executado com o comando sudo?

Obrigado

Alguém poderia explicar isso?

john@john-pcRefs:~/pCloudDrive/someFolder$ ls -al
total 16
drwxr-xr-x 2 john john  4096 Jan 11  2022 .
drwxr-xr-x 4 john john  4096 Jan 11  2022 ..
-rw-r--r-- 1 john john 10439 Sep 22 18:48 EnvironmentSetup.sh
-rw-r--r-- 1 john john  3370 Mar 25  2023 GitInitialization.sh
-rw-r--r-- 1 john john   342 Jul 10  2023 InitDatabase.sh
john@john-pcRefs:~/pCloudDrive/someFolder$ echo $USER
john
john@john-pcRefs:~/pCloudDrive/someFolder$ sudo chmod +x GitInitialization.sh 
chmod: cannot access 'GitInitialization.sh': Permission denied

Se puder ajudar, estou trabalhando em uma unidade de nuvem e acabei de migrar do Ubuntu 22 para o Ubuntu 24.