Estou executando um sistema desktop Ubuntu 12.04. Até agora, instalei apenas alguns programas (tenho direitos sudo).

1. Quando eu checo a lista de usuários no sistema, vejo uma lista longa, como mais de 20 usuários - quando esses usuários foram criados (por exemplo, daemon, sys, sync, jogos, pulso, etc.)? Como eles estão relacionados aos novos programas que estão sendo instalados?

2. Se eu executar um programa no meu sistema, ele deverá ser executado com o meu UID. Mas, ao fazer um ps , vejo muitos outros programas sendo executados com UID diferentes (como root, daemon, avahi, syslog, colord etc.) - como esses programas foram iniciados com UIDs diferentes?

As contas de usuário são usadas não apenas para usuários humanos reais, mas também para executar serviços do sistema e, às vezes, como proprietários de arquivos do sistema. Isso é feito porque a separação entre os recursos dos usuários humanos (processos, arquivos etc.) e a separação entre os recursos dos serviços do sistema requer os mesmos mecanismos.

Os programas que você executa normalmente são executados com seu ID do usuário. Apenas os daemons do sistema são executados sob sua própria conta. O arquivo de configuração que indica quando executar o daemon também indica qual usuário deve ser executado ou o daemon muda para uma conta não privilegiada após o início. Alguns daemons requerem privilégios administrativos totais, portanto, eles são executados na conta raiz . Muitos daemons precisam apenas acessar um dispositivo de hardware específico ou arquivos específicos; portanto, eles são executados em uma conta de usuário dedicada. Isso é feito por segurança: dessa forma, mesmo se houver um bug ou configuração incorreta em um desses serviços, não poderá levar a um ataque completo ao sistema, porque o invasor ficará limitado ao que esse serviço pode fazer e não será. capaz de sobrescrever arquivos, espionar processos, etc.

No Ubuntu, os IDs de usuário no intervalo de 0 a 99 são criados na instalação do sistema. 0 é raiz; muitos no intervalo de 1 a 99 existem apenas por razões históricas e são mantidos apenas para compatibilidade com versões anteriores de algumas instalações locais que os usam (algumas entradas extras não prejudicam). Os IDs de usuário no intervalo de 100 a 1999 são criados e removidos dinamicamente quando serviços que precisam de um ID de usuário dedicado são instalados ou removidos. O intervalo de 1000 em diante é para usuários humanos ou qualquer outra conta criada pelo administrador do sistema. O mesmo vale para grupos.

Presumo que você encontre esta lista de usuários verificando /etc/passwd? Isso é totalmente normal - 'usuários' servem para transportar um conjunto de permissões, úteis para bloquear não apenas 'usuários reais', mas também programas para determinadas áreas do sistema e rastrear o que eles mudaram (mesmo conceito com grupos).

Inseri um dos meus /etc/passwdarquivos Raspberry Pi abaixo para sua referência; você notará o usuário ntopna parte inferior deste arquivo, criado pelo programa ntop(monitoramento de rede). Da mesma forma sshd, gnatsrelatórios de erros etc.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

Quando esses usuários foram criados?

Nos casos mencionados, eles foram criados na instalação do sistema. Essas contas de usuário são convencionais, algumas datando de décadas atrás. Eles também são padronizados. A base padrão do Linux os divide em:

• a necessária utilizador padrão contas, root, bin, e daemon; e
• o opcional contas de usuário padrão adm, lp, sync, shutdown, halt, mail, news, uucp, operator, man, enobody

Outras contas de usuários que são mencionados aqui - pulse, avahi, colorde Debian-exim(para escolher um de arquivo de senhas do py4on) - levar-nos a sua pergunta seguinte.

Como eles estão relacionados aos novos programas que estão sendo instalados?

As contas de usuário não padrão são criadas e destruídas pelos "scripts de manutenção" para vários pacotes, à medida que esses pacotes são instalados e eliminados. Uma conta de usuário será criada pelo chamado postinstscript mantenedor do pacote , que é executado getentpara verificar se a conta do usuário já existe e useraddse não existe. Em teoria, ele seria excluído pelo postrmscript de mantenedor do pacote , em execução userdel.

Na prática, as contas de usuário para pacotes não são excluídas. O wiki do Fedora (qv) explica que isso seria difícil. Veja o bug Debian # 646175 para um exemplo dessa lógica em ação, na qual é decidido simplesmente não excluir a rabbitmqconta do usuário quando o pacote for eliminado, para resolver um problema com um daemon que continua sendo executado sob a égide dessa conta.

Como esses programas foram iniciados com diferentes UIDs?

No Unix e Linux, um processo em execução sob a égide do superusuário pode alterar sua conta de usuário para outra coisa e continuar executando o mesmo programa, mas o inverso não é permitido. (É necessário usar o mecanismo set-UID.)

O sistema de gerenciamento daemon é executado como superusuário. Seus dados de configuração especificam que daemons específicos são executados sob a égide de contas de usuário específicas:

• Com o Sistema 5, rco script /etc/init.dusa uma ferramenta auxiliar como start-stop-daemone sua --chuidopção.
• Com um gerente de serviço daemontools família, as runchamadas de script setuidgid, s6-setuidgid, chpst, ou runuidcom o nome da conta do usuário. Existem exemplos disso em /unix//a/179798/5132 que definem a nagiosconta do usuário.
• Com o iniciante, há uma setuidestrofe em um arquivo de trabalho, que especifica a conta do usuário. Isso não é particularmente refinado e, às vezes, se deseja o que é descrito em /superuser//a/723333/38062 .
• Com systemd, há uma User=configuração no arquivo da unidade de serviço, que especifica a conta do usuário.

Quando o sistema de gerenciamento de daemon gera um processo para ser daemon, esses mecanismos eliminam os privilégios de superusuário, para que o processo daemon continue sendo executado sob a égide da conta de usuário sem privilégios.

Há uma explicação bastante longa por que um bom gerenciamento de daemon é feito dessa maneira. Mas você não perguntou o porquê; somente quando, como e de onde. Pr Um resumo muito breve, portanto:

Os sistemas operacionais Unix e Linux isolam processos em execução sob a égide de diferentes contas de usuários. Historicamente, se alguém pudesse assumir o controle de um daemon que funcionava como superusuário, poderia fazer o que quisesse. Um daemon que é executado sob a égide de uma conta sem privilégios, por outro lado, pode acessar apenas arquivos, diretórios, dispositivos e processos que essa conta sem privilégios pode. Um sistema de programas daemon desconfiados mutuamente, todos funcionando sob a égide de diferentes contas de usuário e incapazes de acessar / controlar arquivos / diretórios / processos / dispositivos (internos, confiáveis) uns dos outros, portanto, é muito mais difícil de decifrar.

Leitura adicional

• Jonathan de Boyne Pollard (2014). Uma olhada lado a lado nos scripts de execução e nas unidades de serviço. . Respostas Frequentes.
• Tratamento de contas em scripts de manutenção . Wiki do Debian.
• Empacotamento: UsersAndGroups . Wiki do Projeto Fedora.
• "Capítulo 15. Usuários e Grupos" . Especificação básica do Linux 2.1 . 2004. Grupo de padrões livres.
• "9.2 Usuários e grupos" . Manual de Políticas Debian . 22/11/2014. A Lista de Discussão da Política Debian.
• "37.3. Usuários padrão" . Guia de implantação do RHEL . 11ª Edição. 2013. Red Hat.
• Usuários e grupos . Arch wiki.
• Carol Hurwitz e Scott McPeak (2001-02-12). Abula os Daemons Raiz! . DOI 10.1.1.120.3567 .

No Linux, quando instalamos um serviço, ele cria um usuário com seu nome de serviço ou semelhante ao que não pode acessar outros arquivos.