Por que o proprietário da pasta não pode gravar em uma pasta criada por um usuário diferente?

Question

Acabei de criar um novo diretório chamado sync no local /home/sync . Eu criei o diretório como usuário liam , então eu fiz um chown -R rslsync:rslsync /home/sync . Isso mudou o proprietário para o usuário rslsync sem problemas. Eu adicionei-me, liam , ao grupo rslsync .

Eu então criei outra pasta no diretório chamado test , então o diretório agora é /home/sync/test . Quando tento apontar a localização da pasta rslsync para /home/sync/test , ele me diz que rslsync não tem permissões de gravação para a pasta. Eu corro um ls -l e mostra root root .

Como um proprietário da pasta de diretório superior rslsync não tem acesso a uma de suas subpastas criadas por outro usuário que esteja no mesmo grupo que ele? Estou faltando alguma coisa aqui?

EDITAR

drwxr-xr-x. 3 rslsync rslsync 18 Aug 26 17:09 /home/sync

drwxr-xr-x. 2 root    root     6 Aug 26 17:09 /home/sync/test

Quando criei a pasta test , usei sudo , pois, de outra forma, não permitiria minha criação.

O grupo liam mostra como isso

liam : liam wheel rslsync

    

Answer 1

Novos diretórios e arquivos criados por padrão herdam o usuário e grupo do processo de criação. O processo pode explicitamente configurá-lo para algum outro grupo (o processo é membro de) ou deve o diretório ter setuid / setgid bit set, o proprietário / grupo são definidos para coincidir com o diretório.

As permissões de arquivo padrão são determinadas pelo processo ' umask . Os valores usuais de umask ( 022 e 027 ) não definem arquivos e diretórios como sendo graváveis.

Como o proprietário e o grupo do seu diretório são root:root , não é possível gravar nele. Também pela sua descrição parece que você criou o arquivo como root (usando o sudo?) Ao invés do usuário liam .

Observe também que as verificações de permissões de arquivos no Linux são feitas para o caminho completo a partir do diretório atual. Se um diretório dentro do caminho não tiver a permissão executar (+ x) para o usuário / grupo do processo, o acesso será negado.

Outra maneira de definir permissões de arquivo é por Listas de Controle de Acesso POSIX, para as quais a semântica é explicada em man 5 acl . O suporte da ACL depende do sistema de arquivos que você está usando e pode exigir um sinalizador de montagem para ativar.

    

Answer 2

1. No Linux, a propriedade e as permissões de cada arquivo ou pasta são tratadas separadamente de todas as outras pastas e arquivos, independentemente do estado dos diretórios pai. Quando você cria uma nova pasta (em qualquer local), ela obtém a propriedade do usuário que a criou. Isso é uma coisa boa e é essencial para o modelo de segurança do Linux.

2. Quando o comando ls lhe dá "root: root" então root criou o arquivo / pasta (ou alguém fez chown root:root . Mas aparentemente o usuário rslsync (ou liam) não pertence (e não deveria) para o grupo "root". É por isso que eles não recebem as permissões que estão no campo "group" dos sinalizadores de permissão. Em vez disso, eles obtêm as permissões que são observadas no campo "outros". E as permissões padrão para esses campos não são permissões ...

Answer 3

você já respondeu à sua pergunta ...

ls -l mostra root: root e você escreveu chown -R rslsync: rslsync .

Isso significa que, pelo menos, se o seu usuário rslsync não fizer parte do grupo root , você não poderá escrever nesse diretório.

O que eu não estou seguindo aqui é por que seu usuário liam cria pastas como root:root , mas isso é um problema diferente.

você poderia, por favor, mostrar a saída de groups do seu usuário?

    

Answer 4

Isso é o que é suposto fazer: novos arquivos (e diretórios) são criados com uid e gid of creator.

Mas as verdadeiras questões são "o que você pode fazer sobre isso?"

• Use uma lista de controle de acesso (ACL) com um grupo padrão: isso fará com que esse grupo e permissões sejam herdados por todos os diretórios e arquivos adicionados. (veja também O que são as diferentes formas de configurar permissões de arquivos, etc. no gnu / linux )

• Se você não puder ter ACLs, certifique-se de ter um grupo privado como grupo principal e defina umask como rwxr-x --- (0027). Em seguida, defina o bit sgid para o diretório. (isso é muito mais difícil de acertar se comparado ao método ACL.)

Nota: não tente usar o suid bit, não funcionará.