Propriedade estranha de arquivo com o Ubuntu

Question

Normalmente, sabemos quando criamos um arquivo no Linux, o proprietário e o grupo do arquivo serão definidos com o criador. Por exemplo, eu tenho um usuário, usera , depois de executar

usera@srv1:$touch 1.txt

Eu vou encontrar o proprietário deste arquivo será usera, assim como

usera@srv1:$ll
-rw-r--r-- 1 usera usera 0 2012-07-25 14:29 1.txt

Mas agora o resultado é:

-rw-r--r-- 1 root usera 0 2012-07-25 14:29 1.txt

Parece que não apenas o comando de toque, mas também outros, todos têm o mesmo problema. Por exemplo, se eu usar vim para criar um novo arquivo na casa do usera, o que significa que esse usuário tem permissão para criar um arquivo:

usera@srv1:$ vim a.txt

Eu posso entrar na tela de edição, mas não posso salvá-la. A mensagem de erro é a mesma que não temos permissão de gravação nesse arquivo.

Então o que acontece no nosso servidor, o servidor é o Ubuntu 11.04 64bits.

Uma informação extra, mas talvez útil:
Agora todos os novos usuários criados têm problemas semelhantes. usera é sudoer , mas depois de criar um novo usuário normal ( sudo createuser xxx ), atribuir senha e efetuar login com essa nova conta, é o mesmo.

    

Answer 1

A única razão pela qual eu posso pensar que daria tais sintomas das etapas que você descreveu , é que touch (e provavelmente uma grande quantidade de outras ferramentas) é setuid root, que não deveria ser.

Tente executar o comando ls -lH "$(which touch)" em um terminal; é o primeiro bit de execução x ou s ? Se for s (por exemplo, -rwsr-xr-x ), minha intuição seria de que você está olhando para uma instalação com raiz. Note que se o seu sistema foi comprometido, você não pode necessariamente confiar na saída de ls (ou em qualquer outra ferramenta) para ser uma representação precisa da realidade. O $(which touch) será expandido para qualquer que seja o seu shell que julgue ser o caminho completo para o touch binário, então isso irá capturar o caso de um touch perdido em um lugar errado que acontece antes do real em seu $PATH , e -H torna ls os links simbólicos de referência (no caso de links simbólicos, ele mostrará o nome do link simbólico, mas as propriedades do arquivo serão do destino do link simbólico).

Se não é isso, pelo que parece, seu sistema está muito seriamente quebrado em termos de permissão.

Lembre-se também que vim não cria realmente o arquivo até que você forneça um comando de salvamento.

Se o seu sistema foi de fato comprometido, a única solução real é limpá-lo e reconstruí-lo, restaurando cuidadosamente os dados e a configuração dos backups. (Você tem backups, certo?) Em princípio , certamente é tecnicamente possível reparar um sistema enraizado, mas tende a ser muito mais problemático do que vale a pena, é extremamente fácil perder algo e certamente não é mais fácil do que reinstalar. O que isso envolveria é inicializar a partir de trusted , mídia somente leitura, montar as partições existentes em seus locais habituais sob alguma raiz alternativa como / mnt e passar por cada diretório, arquivo, bit de permissões , etc etc, com um pente de dentes finos, procurando por quaisquer anomalias e restaurando qualquer coisa, mesmo remotamente de aparência suspeita de uma cópia confiável. Para isso, você precisa efetivamente de um sistema confiável configurado de forma idêntica para comparar; você não pode confiar em nada em um host comprometido.

    

Answer 2

Parece que o seu binário touch é root setuid.

Verifique isso usando:

$ ls -l 'which touch'
-rwxr-xr-x 1 root root 64192 Jan  8  2012 /bin/touch
#  ^ 

Se a coluna marcada tiver um s em vez de um x , o arquivo é de fato setuid root. Você pode corrigir isso executando chmod u-s 'which touch' como raiz (por exemplo, via sudo ).

No entanto, você deve considerar a verificação de backdoors no seu sistema, etc. Se binários aleatórios forem definidos, é provável que alguém tenha invadido e substituído binários inofensivos por variantes setuid que contenham alguma funcionalidade "extra".

    

Answer 3

Você tem acesso de leitura em um.txt para que o vim possa abri-lo. Ele deve indicar que o arquivo é somente leitura e avisa quando você começar a fazer alterações (mas ainda permitir editar o buffer na memória).

Quando você tenta salvá-lo, você não tem permissão de gravação para que o salvamento falhe. Você pode, obviamente, dizer ao vim para salvá-lo em outro nome de arquivo / diretório onde você tenha permissão de escrita.

    

Answer 4

Sim, o problema é o bit suid para toque e outro comando do problema.

-rwsr-xr-x 1 root root 64192 8 de janeiro de 2012 / bin / touch

Embora tenhamos encontrado a causa raiz, temos que reconstruir todo o sistema porque não sabemos quantos arquivos binários foram afetados. E ainda estamos tentando descobrir o que causa isso. É apenas um servidor para uso interno e não é publicado na internet.

Obrigado a todos pela ajuda.