IDs de grupos pré-definidos nas distribuições Linux?

Question

Para implementar com êxito o acesso w / r via ACL para o armazenamento externo com o ext4 fs , preciso atribuir o ID de grupo padrão aos arquivos armazenados.

LSB_5.0.0 diga:

This specification makes no attempt to numerically assign user or group
identity numbers, with the exception that both the User ID and Group ID
for the user root shall be equal to 0.

Vergonha para os fornecedores de Linux!

Existe alguma convenção sobre ids de grupo entre as principais distribuições Linux?

Na política do Debian, descobri que os valores de grupo padrão definidos por base-passwd package em /usr/share/base-passwd/group.master file. Entre eles, esses grupos parecem bons candidatos para os padrões da ACL:

tape:*:26:
backup:*:34:
operator:*:37:
plugdev:*:46:
staff:*:50:
users:*:100:
nogroup:*:65534:

Nunca trabalha com documentos de política de distros do Suse / RH / Slackware ... Também é interessante se o FreeBSD / OpenBSD / MacOS compartilharem convenções com distribuições do Linux.

UPDATE Eu comparo o MacOS X ( dscacheutil -q group ) com o Debian e apenas alguns IDs do grupo são correspondidos:

sys:*:3:

UPDATE 2 Eu comparo o arquivo FreeBSD e o Debian /etc/group , apenas 2 correspondências:

daemon:*:1:
sys:*:3:

    

Answer 1

Como você descobriu, não há um padrão para o mapeamento username-uid e groupname-gid. Até mesmo as contas do sistema comumente usadas que não fazem parte do sistema básico podem ter diferentes uids ou gids em sistemas que executam exatamente o mesmo SO; isso depende da ordem em que os pacotes foram instalados. Os pacotes geralmente usam apenas getent passwd username || useradd username durante a instalação.

Assim, a melhor opção é escolher seus próprios uids e gids, fora do intervalo do sistema.

Em alguns sistemas, haverá um arquivo de configuração como /etc/login.defs com entradas como:

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN                  1000
UID_MAX                 60000
# System accounts
SYS_UID_MIN               201
SYS_UID_MAX               999

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN                  1000
GID_MAX                 60000
# System accounts
SYS_GID_MIN               201
SYS_GID_MAX               999

Escolha qualquer coisa dentro dos intervalos não SYS. Uma possibilidade é usar o intervalo 59001.59999 para uso administrativo em todo o site. Você pode editar o arquivo login.defs para definir UID_MAX e GID_MAX como 59000, para evitar conflitos.

    

Answer 2

Não existem convenções relativas a IDs de grupo. Geralmente, a configuração de autorização é considerada parte da política local e, em geral, não tem nada a ver com entradas em um arquivo local /etc/passwd ou /etc/group .

Os grupos usados para decisões de autorização normalmente vêm de um diretório centralizado (LDAP, AD etc.) e diferem de organização para organização e não têm relação com a distribuição (ou sistema operacional) em uso.

    

Answer 3

Descobri que sys id de compartilhamento de grupo 3 no Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

Nenhum outro nome de grupo compartilha o mesmo id. Mesmo o root group com id 0 em alguns sistemas, na verdade, é wheel . E nogroup no Linux geralmente é 65534 , mas no NetBSD é 32766 . Diferentes distribuições possuem diferentes nomes humanos legíveis para este grupo, como: nogroup (Debian), nfsnobody (RedHat), nobody (FreeBSD), nobody (MacOS).

As especificações POSIX, SUSv4, LSB, etc não definem IDs de grupos.

sys marcado como obsoleto nos documentos do Debian.

Com sys group e setgid bit e ACL, é possível fazer com que o volume ext4 se mova entre os hosts sem entrar em conflito com as permissões após:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chgmod -R g+s /mnt/data/dir
$ sudo fsetacl -R -m g:sys:rwx /mnt/data/dir
$ sudo fsetacl -R -d -m g:sys:rwx /mnt/data/dir