Por que chmod g + s está em um diretório sendo ignorado?

Question

Eu tenho um repositório git (na verdade, git-annex) que estou tentando tornar compartilhado, parte do qual envolve a configuração do bit set-group-id em vários diretórios. Isto está em uma caixa Debian GNU / Linux Stretch, em um sistema de arquivos ext4. Por algum motivo estranho, chmod g+s DIRECTORY está sendo ignorado (linhas em branco ao redor de chmod são adicionadas para facilitar a leitura):

$ stat objects
  File: objects
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd06h/64774d    Inode: 12353692    Links: 260
Access: (0775/drwxrwxr-x)  Uid: ( 1000/ anthony)   Gid: ( 1025/git-books)
Access: 2018-07-30 14:43:13.831641743 -0400
Modify: 2018-07-28 14:28:14.970667931 -0400
Change: 2018-07-30 14:46:38.179597449 -0400
 Birth: -

$ chmod g+s objects
$ echo $?
0

$ stat objects
  File: objects
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd06h/64774d    Inode: 12353692    Links: 260
Access: (0775/drwxrwxr-x)  Uid: ( 1000/ anthony)   Gid: ( 1025/git-books)
Access: 2018-07-30 14:43:13.831641743 -0400
Modify: 2018-07-28 14:28:14.970667931 -0400
Change: 2018-07-30 14:50:43.355539381 -0400
 Birth: -

O que eu verifiquei até agora:

• Não parece haver nenhuma opção estranha de montagem (por exemplo, nosuid ) que possa impedir o funcionamento. Eu chequei tanto fstab e /proc/mounts , que mostra /dev/mapper/slow-srv /srv ext4 rw,relatime,nobarrier,errors=remount-ro,stripe=384,data=ordered 0 0
• Não parece haver nenhuma ACL estranha no diretório; para ter certeza de que fiz setfacl -b objects . Mesmo depois de fazer isso, o chmod continuou a não funcionar.
• strace on chmod mostra o sucesso do syscall e tem o bit sgid definido:% fchmodat(AT_FDCWD, "annex", 02775) = 0
• Outros diretórios no mesmo sistema de arquivos possuem o bit set-group-id configurado. Na verdade, eu defini alguns anteriormente na mesma sessão, em um repositório git-annex diferente.

Answer 1

Acontece que, embora eu tenha criado esse grupo e adicionado a ele há vários dias, e isso era o que eu achava uma nova conexão ssh, não era realmente. Devido ao uso do recurso de multiplexação de conexão do OpenSSH ( ControlMaster / ControlPath / etc.), Eu estava realmente logando em uma conexão que tinha ~ 10 dias, então minha sessão (processos) não tinha o novo grupo configurado. Eu confirmei isso com id .

Depois de fazer login via ssh -o ControlPath=none HOST , id confirma que minha sessão tem o grupo git-books e o chmod g+s funciona.

Quanto ao motivo pelo qual isso não deu um erro de permissão negada, parece que o padrão requer esse comportamento para arquivos e permite que implementações ignorem os bits:

If the calling process does not have appropriate privileges, and if the group ID of the file does not match the effective group ID or one of the supplementary group IDs and if the file is a regular file, bit S_ISGID (set-group-ID on execution) in the file's mode shall be cleared upon successful return from chmod().

Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored.

Single Unix Spec v4 2018 edition, chmod. http://pubs.opengroup.org/onlinepubs/9699919799/functions/chmod.html (registration may be required).

Provavelmente, retornar um erro seria meramente sã, não em conformidade ☹.