Me deparei com uma coisa interessante: em sistemas BSD, um novo arquivo terá group definido para o grupo do diretório. Em sistemas System V, terá o grupo principal do usuário que criou o arquivo. Quanto aos sistemas BSD, qual é o propósito de tal comportamento e isso significa queSGIDpouco é inútil aí?
Responder1
Isso pode ou não ser um recurso dependente do sistema operacional; você não forneceu detalhes suficientes para saber.
O bit sgid em um executável faz com que ele seja executado no grupo do arquivo, mesmo que o usuário que o executa não esteja nesse grupo. (definir ID do grupo) Se não for executável, o bit sgid é praticamente discutível.
Em um diretório, o bit sgid foi reaproveitado para controlar a herança de grupo dentro do diretório. Se o bit sgid estiver definido em um diretório, os arquivos criados no diretório herdarão o grupo (mas não as permissões do grupo). O objetivo disso é que, se você tiver um diretório compartilhado usado por usuários em um grupo, todos eles poderão definir sua umask como 002 em vez de 022 e editar os arquivos no diretório sem a necessidade de corrigir constantemente as permissões do grupo. (Sem a alteração umask, isso é menos útil.)
Então, possivelmente nos dois sistemas que você estava olhando, um tinha o bit sgid definido no diretório em que você estava testando e o outro não. Esse recurso não existe desde sempre, portanto, se um dos sistemas for suficientemente antigo, ele poderá não suportar herança de diretório sgid. (Mas já existequasepara sempre, então isso é improvável.)
Isso de forma alguma torna o sgid inútil, não sei por que você pensaria isso, você não explicou o que acha inútil. Observe que se um arquivo tiver um proprietário de grupo para um grupo do qual você não faz parte, você não poderá tornar o arquivo sgid sem primeiro alterar o proprietário do grupo e, se um usuário não root copiar o arquivo, o sgid será descartado.