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?
- suporta permissões de arquivo padrão Linux
- é 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.
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:
- 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?
- 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)
- 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.
Estou encontrando um erro de "Permissão negada" ao tentar acessar o link de símbolo de um processo de trabalho nginx em execução sob o adgusuário.
Pergunta semelhante: o proprietário não consegue ler /proc/$pid/io , mas é um pouco diferente. Meu problema é que os links de símbolos não podem ser acessados e a saída ls -lcontém o erro "Permissão negada" (de stderr) e resultado normal (de stdout). A saída específica é a seguinte:
- Imprima as informações do processo de trabalho nginx e seu fd:
root# ps -fp 2728114
UID PID PPID C STIME TTY TIME CMD
adg 2728114 2723696 0 21:11 ? 00:00:00 nginx: worker process
root# stat /proc/2728114/fd/0
File: /proc/2728114/fd/0 -> /dev/null
Size: 64 Blocks: 0 IO Block: 1024 symbolic link
Device: 0,21 Inode: 204114580 Links: 1
Access: (0700/lrwx------) Uid: ( 948/ adg) Gid: ( 948/ adg)
- Execute
ls -lcomadgusuário erootusuário:
root# sudo -uadg ls -l /proc/2728114/fd/0
ls: cannot read symbolic link '/proc/2728114/fd/0': Permission denied
lrwx------ 1 adg adg 64 Aug 20 21:12 /proc/2728114/fd/0
root# sudo -uadg -gadg /bin/sh -c 'ls -l /proc/2728114/fd/0'
ls: cannot read symbolic link '/proc/2728114/fd/0': Permission denied
lrwx------ 1 adg adg 64 Aug 20 21:12 /proc/2728114/fd/0
root# ls -l /proc/2728114/fd/0
lrwx------ 1 adg adg 64 Aug 20 21:12 /proc/2728114/fd/0 -> /dev/null
- Verifique usuário e grupo:
root# grep adg /etc/passwd
adg:x:948:948::/home/adg:/sbin/nologin
root# id -nu 948; id -ng 948
adg
adg
- Verifique o status de
selinux
root# sestatus
SELinux status: disabled
rooto usuário pode acessar o fd normalmente, mas o proprietário não, alguém poderia me ajudar a solucionar isso?
Criei dois usuários em meu sistema Mint 21.3:
user1(1000) foi criado durante a instalaçãouser2(1001) adicionei mais tarde
Ambos têm seus diretórios pessoais em /home, com exatamente as mesmas drwxr-x---permissões. Nenhum deles é criptografado.
O problema é que nenhuma das distros que experimentei como pendrives live (Ubuntu e sabores, Mint, Fedora e spins) me permite acessar arquivos /home/user2. A maioria, mas não todos, permitem /home/user1. A única diferença entre os usuários é que ele user1é administrador e user2não é.
Minha pergunta: por que isso acontece?
Gostaria que outros usuários do meu grupo pudessem acessar uma pasta específica no meu espaço de arquivos (e suas subpastas), sem poder acessar o restante dos meus arquivos.
[O motivo é que desejo compilar um aplicativo instrumentado para fazer cobertura de código usando gcov; os vários arquivos .gcno são gravados em meu diretório de construção, e eu gostaria que meus colegas, durante a execução de seus testes, acessassem esses arquivos e gerassem os arquivos .gcda que serão colocados ao lado deles.]
De qualquer forma, eu ingenuamente pensei que poderia fazer:
chmod g+w -fR build_directory
... e com certeza isso resulta no diretório de construção e todos os seus subdiretórios com permissões drwxrwxr-x. e todos os seus arquivos com permissões -rw-rw-r--. Mesmo assim, meus colegas do grupo relatam que mesmo tentando executar
ls -l <full path to build_directory>
retorna "Não é possível acessar: esse arquivo ou diretório não existe".
O que estou perdendo?