Perguntas[permissions](unix)

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.

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 -lcom adgusuário e rootusuá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 deselinux

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ção
• user2(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?

O que o comando a seguir faz? sudo chmod -R a=,a+rX,u+w,g+w /data

Entendo que isso altera as permissões, mas o que exatamente e como?

Por que a configuração umasktorna 0077uma chave pública gpg indisponível aptao instalar um pacote, por exemplo , .

umask 0077
curl -fsSLo /usr/share/keyrings/brave-browser-beta-archive-keyring.gpg https://brave-browser-apt-beta.s3.brave.com/brave-browser-beta-archive-keyring.gpg
  echo "deb [signed-by=/usr/share/keyrings/brave-browser-beta-archive-keyring.gpg] https://brave-browser-apt-beta.s3.brave.com/ stable main">/etc/apt/sources.list.d/brave-browser-beta.list
apt update
apt install brave-browser-beta
  

O procedimento acima não funciona, recebo esta saída:

Err:4 https://brave-browser-apt-beta.s3.brave.com stable InRelease    
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0B31DBA06A8A26F9
Reading package lists... Done
W: GPG error: https://brave-browser-apt-beta.s3.brave.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0B31DBA06A8A26F9
E: The repository 'https://brave-browser-apt-beta.s3.brave.com stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Isso funciona:

umask 0022
curl -fsSLo /usr/share/keyrings/brave-browser-beta-archive-keyring.gpg https://brave-browser-apt-beta.s3.brave.com/brave-browser-beta-archive-keyring.gpg
  echo "deb [signed-by=/usr/share/keyrings/brave-browser-beta-archive-keyring.gpg] https://brave-browser-apt-beta.s3.brave.com/ stable main">/etc/apt/sources.list.d/brave-browser-beta.list
apt update
apt install brave-browser-beta

Por que configurar umask( 0077e depois baixar a chave pública) torna uma chave pública gpg indisponível para o apt? A chave foi baixada como roote executada apt update, por que então esse problema?

Eu tenho uma pasta em /mnt/ com permissões drwxrwxrwx e em root:root

Em seguida, montei uma unidade USB (exFAT) nesta pasta e ela se tornou drwxr-xr-x

O problema é que agora não consigo fazer scp para essa pasta via WinSCP, pois não há permissão para o grupo gravar na pasta e não consigo fazer scp como usuário root.

Estou montando o drive via fstab com o seguinte:

/dev/sdb2       /mnt/USB    exfat   defaults,dmask=0000,umask=0000,rw       0       0

Como posso: 1) Conceder permissão para gravação em grupo ou 2) Montá-lo como um usuário não root para que esse usuário possa escrever?

Eu tentei chown e chmod sem sucesso. Chown mesmo quando executado como root retorna Operação não permitida

Consigo gravar na montagem como usuário root quando estiver em SSH (como mkdir), portanto, a montagem pode ser escrita, mas apenas pelo root.

Tenho o diretório /dataque desejo compartilhar com todos os usuários do datagrpgrupo. Eu configurei todas as permissões e agora tenho

drwxrwsr-x 2 root datagrp 4.0K Apr 22 14:52 /data

Agora todos os usuários podem ler e escrever lá, o que é normal. No entanto, se o usuário useracriar uma pasta /data/a, os outros usuários não poderão gravar nela, a menos que eu defina manualmente as permissões. Eu gostaria que isso fosse automático, ou seja, que tudo o que está dentro /datapossa ser visto e modificado por qualquer usuário do datagrp. Como isso pode ser feito?

eu já tentei

sudo chown :datagrp /data/
sudo chmod 770 /data/
sudo chmod g+s /data/

e

sudo setfacl -dm u::rw,g::rw,o::r /data