26

Acabei de executar isso alguns segundos atrás. Consegui fazer Ctrl- Cassim que percebi o que comecei a fazer.

Até agora, o único diretório pelo qual ele começou a ser é /bin.

Eu tenho medo de fazer qualquer outra coisa. Até agora, percebi que não posso mais usar sucomo meu usuário normal.

Felizmente ainda tenho outro terminal raiz aberto. O que eu faço?

— Vai
fonte

26

Parece que você foi criticado por lá, amigo.

— ta.speot.is

4

Agora você entende a importância dos backups. Faça isso regularmente.

— Juliano

Pelo menos ele não chmod da raiz. Isso é um desastre total. Pelo menos rm -rf from root oferece mais espaço em disco e prepara você para uma reinstalação completa do sistema, o chmod deixa uma bagunça real que é muito difícil de recuperar por qualquer coisa além de uma reinstalação completa do sistema. A grama é marrom nos dois lados da cerca, não é?

— Fiasco Labs

10

Quase tudo em / bin / deve pertencer a root: root, portanto, se você executar o seguinte, poderá corrigir a propriedade desses arquivos:

chown root:root -R /bin/

Você também pode verificar se o bit setuid está definido corretamente em / bin / su, que pode ser corrigido com o seguinte:

chmod 4755 /bin/su

— epic9x
fonte

1

No Ubuntu, é especialmente importante fazer o mesmo com o sudo. Eu não acho que uma senha root seja definida por padrão? A propósito, eu realmente recomendo realmente usar o sudo em vez de cascas de raiz. O meio segundo necessário para digitar sudo normalmente interrompe erros como esse nas faixas. Apenas trabalhando em um shell de root é mais fácil de miss ...

— Bernd Haug

4

O paste.ubuntu.com/362468 é um "ls -l / bin" da área de trabalho do Ubuntu 9.10. Embora eu possa não ter exatamente os mesmos arquivos instalados, você deve fornecer pelo menos uma boa dica sobre quais arquivos precisam de permissões especiais.

— andol

@ Bernd: Embora eu não faça muito trabalho administrativo, notei que sudo menos coisas idiotas do que como root. Talvez eu nunca mais use uma senha root. (E não, não há nenhuma senha de root padrão no Ubuntu, e eu não acho que há uma em MacOSX.)

— David Thornley

@ David: Definitivamente, não existe uma senha root padrão no OS X, e definir uma é principalmente um erro, IMO. Quase sempre há outra maneira melhor. O problema é que os Macs não são muito seguros para começar; Espero ver muita 'diversão', uma vez que eles tenham uma base de instalação maior para tornar rentáveis os clientes RKs, Virii, Botnet etc.

— Bernd Haug

36

Usuário Redhat:

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Usuário Debian / Ubuntu:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

Enquanto a tela estiver em execução, faça isso pelo menos duas vezes:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

Preste muita atenção à saída, pois se ela reclama de algo com permissões erradas, você deve corrigi-la em outra janela da tela.

Crash course in screen:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Usuário do Solaris:

Você está fodido.

pkgchk -R / -f -a

redefinirá todas as permissões, mas o setuid-ness ainda será quebrado. Use um backup ou outra máquina solaris para procurar por scripts e arquivos setuid / setgid e corrigi-los manualmente.

A COISA IMPORTANTE SOBRE BACKUPS

É que você pode recuperá-los, não que você os leve.

Outras pessoas deram conselhos para você fazer backups, mas quero acrescentar que você deve testá-los. Se você estiver usando um sistema unixish, não há nenhuma razão para que você não possa despejar os arquivos em outra máquina periodicamente e verifique se tudo funciona.

— geocar
fonte

Usuário do FreeBSD: nunca cometeria esse tipo de erro;)

— einstiien

10

@einstiien Sim, os usuários do FreeBSD vão direto ao rm -rfpalco.

— grawity

@ grrawity: lol, bom.

— einstiien

Usuários pobres do Solaris :(

— Mircea Chirea

3

Esteja ciente de que os sinalizadores set-uid em quaisquer binários afetados também podem ter sido removidos; esse é um recurso de segurança do chown. Verifique com algum outro sistema quais binários possuem os sinalizadores set-uid ou set-gid e certifique-se de configurá-los também em seus binários.

— Teddy
fonte

3

Eu explicaria os detalhes do uso do RPM para redefinir as permissões de arquivo, mas encontrei um site com muito mais informações . Ele também menciona que o Ubuntu / Debian (então .debs em geral) não o suporta.

Mas, em geral, a opção que você procura seria na mesma linha:

rpm --setugids {packagename}

— Cooperativas
fonte

Este é um sistema ubuntu, conforme indicado pelas tags. Isso significa que o dpkg e o .DEBs são usados em vez de rpm e .RPMs #

— Kevin M

2

Se este fosse um sistema debian, eu aptitude reinstalaria tudo.

— ptman
fonte

0

você tem um backup de trabalho? quando sim, restaure sua pasta bin.

caso contrário, olhe para outra caixa onde você instalou a mesma versão do ubuntu e o chownque você encontra na instalação em funcionamento.

— cristão
fonte

0

tente isto: encontre todos os dados www no diretório / bin

# find /bin -user www-data

depois mude os dados www de volta para o usuário original

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

— squillman
fonte

0

Obrigado a todos pelas ótimas respostas, tudo parece estar resolvido agora.

/ bin / su funcionou uma vez chmod'd para 4755 (não sei por que chown mudou o bit suid)

Eu não percebi, mas ele também começou a trabalhar no diretório / home, mas isso foi uma solução bastante fácil (basta definir user: group para o usuário para cada dir)