Hjæællp - jeg har lavet rod i filrettighederne i /etc !

Tja du har lige det problem at der ikke er nogen "sådan er rettighederne i /etc". /etc mappen indeholder blandt andet en bunke scripts som bruges ved opstart af systemet og en masse konfigurationsfiler. Disse filer skal jo klart nok have forskellige rettigheder.

Jeg ville nok bare geninstallere i sådan et tilfælde :)

Det lyder temmelig drastisk. Der må være andre muligheder.

Fx blot tilføje o+rwx til alle filerne i /etc, hvis jeg altså bare kunne starte en terminal.

Jeg tror jeg ved hvad der (blandt andet) er på spil:

Jeg regnede med at det ville være OK at fjerne rettighederne for others, dvs. andre end ejer og gruppe, men der er jo det problem at kørselsrettigheder har en anden betydning for mapper: Her bestemmer kørselsrettigheder om man kan læse mapperne.

Jeg kan nemlig godt dykke ned i /etc med nautilus, men ikke ned i undermapperne. Så systemet kan altså ikke læse konfigurationsfilerne med mindre de ligger i selve /etc.

Vær varsom med at bruge * sammen med chmod. På den måde ændrer du alle filer og alle directories incl. ./ , altså også /etc selv. Da directories skal have x sat, for at man kan få adgang til dem, vil det selvfølgeligt skabe problemer, når man fjerner det.

I min /etc (Mandriva 2009.1) har alle directories på nær et rettighederne sat til 755. Filerne varierer mere. De fleste har 644, men 644, 664, 600 og 440 findes også. Enkelte, som f.eks. anacrontab, esd.conf og mcc.conf, har 755.

Det er din første kommando, der har gjort skade, så vidt jeg kan se, så du skal sætte x'e tilbage på alle directories (husk også /etc). Har du filer med rettigheder 754, som de tre nævnte ovenfor, skal de nok også ændres til 755.

Kan du ikke starte systemet, så prøv via en live-CD.

#4, tak for svaret. Men hvordan sætter jeg rettighederne tilbage når jeg ikke har nogen terminal? Er det noget med en live cd eller er der andre muligheder?

Og, ja, jeg skal være varsom med chmod * !!! Det har jeg lært nu! Og så skal jeg fremover have backup af /etc.

Tænker så lige på: Er det muligt at logge ind som root når man starter Mint?

Jeg gav lige mig selv en ide: jeg prøvede på min bærbare, og der kunne jeg logge ind som root, både i Gnome og i en terminal.

Jeg må så prøve om jeg kan på min nu "handicappede" stationære computer. Jeg kan end ikke logge ud på rettighedsproblemet, så jeg må vel slukke for den.

Men lader den lige stå lidt for at se om der kommer andre forslag...

Jeg kender ikke Mint, så der kan jeg ikke hjælpe dig. Andre må træde til og fortælle, hvordan man bliver root i din fortrukne live-CD.

Problemet er, at chmod ikke skelner mellem directories og andre filer, så her må du nok bruge f.eks. find.
# find /etc -type d -exec chmod o+x {}
burde kunne gøre det.
OBS: Jeg har ikke prøvet det med -exec, men
# find /etc -type d
retunerer alle directories fra /etc og nedefter.

Jeg ville starte en live-CD, mounte hd'en og prøve med find som root. Tilpas /etc til hvordan den ligger i live-CD-systemet.
Prøv evt. først uden -exec og læs man find.

#7:

Du har helt ret i at man må gå over find for at undlade at fjerne rettighederne fra mapper.

Hvad angår adgangen til systemet, så har jeg nu fået adgang ved at genstarte computeren (måtte tage strømmen, den ville ikke engang lukke ned!) og så starte en rodterminal fra GRUB'en. Her kørte jeg så en

chmod -R o+rw *

i /etc og kunne derefter logge ind normalt.

Det er selvfølgelig ikke elegant, og sikkerhedsmæssigt ret skidt, men i det mindste har jeg nu et fungerende system. Så må jeg se om jeg kan sætte de korrekt rettigheder.

Jeg har i øvrigt en gammel backup af /etc. Ikke ny nok til at jeg kan bruge selve filerne, men jeg har tænkt på om man kan overføre rettigheder fra det sæt filer til det andet? Det skal jeg måske starte en ny tråd om ...

Har du nu ikke fået lavet mere rod ved at sætte o+rw på alle filer og directories? Der er en del filer, der af sikkerhedsmæssige grunde ikke skal have de rettigheder. Og hvad med o+x for directories under /etc?

Det var derfor jeg foreslog, at du skulle bruge find til reparationen.

Jeg skriver lidt flere forslag senere. Jeg har ikke mere tid lige nu.

Jeg læste først dit forslag efter jeg havde gjort det!

Man kan godt sige der er mere rod nu, men på den anden fik jeg da startet systemet, og under alle omstændigheder er der ged i rettighederne som jeg må se at løse ved at sammenligne med backuppen.

Hvis du har din /etc-backup liggende i f.eks. ~/backup/etc kan du sætte rettighederne på filerne i /etc til det samme som den tilsvarende fil i ~/backup/etc på følgende måde (som root eller sudo):

cd ~/backup
find /etc -exec chmod --reference=.'{}' '{}' \;

Det er testet på en enkelt fil og fungerer. Det vigtigt at du har samme filer i samme struktur i din backup som i /etc, ellers kan du være nødt til at lave en test for om referencefilen eksistere og evt. udskrive navnet på de, der ikke gør.
Det er også vigtigt, at din backup ligger i et directory, der hedder etc.

Du er måske så tilbage ved de rettigheder fra før du rettede, men nu ved du så, at man skal være varsom.

#11:

Det ser ud til at kunne gøre det, bortset fra at der vist ikke skal være apostroffer omkring {}

Der er så stadig et problem med symlinkede filer, disse fik jo også ændret rettighederne da jeg rask væk chmod'ede hele molevitten.

#11:

Det ser ud til at kunne gøre det, bortset fra at der vist ikke skal være apostroffer omkring {}

Der er så stadig et problem med symlinkede filer, disse fik jo også ændret rettighederne da jeg rask væk chmod'ede hele molevitten.

Edit: altså problem med filer der eksisterer udenfor /etc men hvor symlinket ligger i /etc

Det skal netop være '{}' for ikke bash skal begynde at fortolke dem.

Jeg kan godt se, at der er et problem med symlinks, da chmod fortolker forskelligt afhængigt af, om det er recursive mode eller ej.

I /etc er der directories, alm. filer og symlinks, så det må kunne klares ved at putte en -type ind:

find /etc -type d -exec chmod --reference=.'{}' '{}' \;
find /etc -type f -exec chmod --reference=.'{}' '{}' \;

Så kan du tage directories og alm. filer hver for sig og undgå symlinks.
De symlinkede filer skulle ikke være blevet ændret, da du brugte chmod rekursivt. Prøv at checke om ikke det er rigtigt.
De filer, der ligger i directories under /etc vil selvfølgeligt være blevet ændret under rekursionen, men filer udenfor som f.eks. /etc/rmt -> /sbin/rmt skulle ikke. Derfor skal du nok under alle omstændigheder undgå symlinks.

Jeg har testet både med og uden apostroffer omkring {} og begge dele virker. Så i dette tilfælde er det åbenbart hip som hap.

Desværre virker chmod -R * også på symlænkede filer, så de har også fået forkerte rettigheder!

Det har jeg dog fundet en snørklet løsning på. Jeg har en bærbar med en næsten identisk konfigurations, så på denne har jeg altså de korrekte rettigheder for symlinkene.

Jeg har brygget denne kommando sammen, som når den køres på min bærbare, giver et script med de korrekte rettigheder. Det kan jeg så køre på min stationære til at sætte rettighederne tilsvarende.


find /etc -type l -exec ls -lL {} \; | awk '{k=0;for(i=0;i<=8;i++)k+=((substr($1,i+2,1)~/[rwx]/)*2^(8-i));if(k)printf("%0o ",k);print}' | sed -r "s#^([[:digit:]][[:digit:]][[:digit:]] )[^\/]*#chmod \1#" > setsymperms.sh


Et par typiske linjer fra outputtet er:

chmod 644 /etc/gtk/gtkrc.et
chmod 644 /etc/gtk/gtkrc.sp

osv.

#15:
det var da en grotesk måde at få gemt dine permissions til en fil

prøv at køre kommandoen:
# cd /etc ; getfacl -R /etc > /root/perms.acl

setfacl kan så restore det.

#16: Det var fikst! Kendte ikke getfacl/setfacl. Man bliver jo hele tiden klogere.

Virker det også korrekt med symlinks? En del af filerne i /etc er symlinks til filer udenfor træet.

Din kommando kunne have sparet mig nogle timer! På den anden side var det nu meget skægt at nørkle med sed og awk.

Hvor er det smart med getfacl og setfacl! Det er lige før det var alt besværet værd for at lære disse nyttige kommandoer at kende.

Dog virker det ikke med symlinks til mapper, de bliver ikke restoret korrekt. Heller ikke selv om jeg bruger getfacl -RL

Er der nogen vej ud af det?

Alternativt, kan man finde symlinks til mapper?

Der er

find -type d : finder mapper
find -type l : finder symlinks

Men kombinere dem så den kun finder symlinks til mapper???

Har nu konstrueret følgende som lister symlinks til mapper:

for f in $(find /etc -type l -print | xargs ls -ld | awk '{print $8}'); do test -d $f && echo $f ; done

Kan det gøres lettere?

Der var kun 4 symlinkede mapper, så nu er hele /etc i orden igen. Puh!

Tak for hjælpen alle sammen!

Ps. vil stadig gerne have at vide om der findes lettere måder at finde alle symlinkede mapper på end den i #20.