Authenticatie op Linux kapot

[VelhaChica]

Ik heb een kleine aanpassing gemaakt in /etc/group. Na deze aanpassing lopen een aantal pakketten helemaal in de soep. Doordat zijn niet meer kunnen authenticeren, starten processen niet meer op. En als ze al opstarten, dan is er nog niets mee te beginnen. Een overzicht:

1. mysqld
   
   070217 17:34:10 mysqld started
   ^G/usr/libexec/mysqld: Can't read dir of '/tmp/' (Errcode: 13)
   ^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ib5dwAJE' (Errcode: 13)
   070217 17:34:10 InnoDB: Error: unable to create temporary file; errno: 13
   070217 17:34:10 [ERROR] bdb: /var/lib/mysql: Permission denied
   070217 17:34:10 [ERROR] bdb: /var/lib/mysql/log.0000000001: Permission denied
   070217 17:34:10 [ERROR] bdb: PANIC: Permission denied
   070217 17:34:10 [ERROR] bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
   070217 17:34:10 [ERROR] bdb: fatal region error detected; run recovery
   070217 17:34:10 [ERROR] bdb: /var/lib/mysql: Permission denied
   070217 17:34:10 [ERROR] Can't start server : Bind on unix socket: Permission denied
   070217 17:34:10 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
   070217 17:34:10 [ERROR] Aborting
   
   070217 17:34:10 [Note] /usr/libexec/mysqld: Shutdown complete
   
   070217 17:34:10 mysqld ended
2. dovecot
   
   Feb 17 17:15:23 coc2 dovecot: imap-login: Login: user=<web8_wg04>, method=plain, rip=::ffff:145.116.9.155, lip=::ffff:217.170.53.62
   Feb 17 17:15:24 coc2 dovecot: child 1828 (imap) returned error 89
   Feb 17 17:15:27 coc2 dovecot: chdir(/var/www/web8/user/web8_wg04) failed with uid 10034: Permission denied
3. httpd
   
   error.log
   
   [Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to / denied
   [Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /error/forbidden.html denied
   [Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /favicon.ico denied
   [Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /error/forbidden.html denied
4. proftpd
5. sshd

Ik het echt geen idee wat hier aan de hand is. Het lijkt er op dat het gebruikersbestand kapot is. Maarja, hoe kun je dit herstellen? Wie helpt mij aan een oplossing? Ik vind dit echt niet cool.

Het systeem draait op Fedora Core 5 op Xen met kernel 2.6.15-1.2054_FC5xenU. Ik weet niet precies welke informatie ik allemaal moet geven. Ik hoor het dus graag. Ik ben nog een behoorlijke newbie.

[Verwijderd]

Het lijkt erop dat de bestandsrechten niet goed staan. Heb je misschien laatst een commando uitgevoerd om recursief alle rechten op een directory te veranderen? Een chmod -R ..... misschien?

Sowieso kunnen de allervreemdste foutmeldingen worden gegenereerd door een volle partitie waarop je /tmp directory staat, maar ik denk niet dat dat nu het geval is.

[edit]
Niet goed gelezen... wat staat er nu in je /etc/group bestand?
En voor dit soort dingen heb je sowieso vigr, dus niet zomaar aan die hele belangrijke bestanden zitten!

Misschien is er nog een /etc/group~ bestand, waarmee je de oude kunt overschrijven. Maar als je nu vrijwel niets meer kunt uitvoeren op die machine, zul je misschien met een rescue disc aan de gang moeten, zodat de /etc/passwd en /etc/group even niet worden gebruikt.

[ Voor 38% gewijzigd door Verwijderd op 17-02-2007 20:16 ]

[imdos]

Als het goed is heb je nog een backup in /etc/group- die je kunt terugzetten om te testen.

En anders kun je altijd nog diff /etc/group /etc/group- doen om te kijken wat er gewijzigd is.

[VelhaChica]

Dit zijn de bestandsrechten op /etc/group*

-rw------- 1 root root 1140 Feb 17 17:46 group
-rw------- 1 root root 1126 Feb 17 17:43 group-
-rw-r--r-- 1 root root 1112 Feb 17 17:07 group.bak

De group.bak is het origineel.

[Verwijderd]

/etc/group moet door iedereen te lezen zijn
De rechten op het origineel staan goed, de rechten op /etc/group- make niets uit.

Een chmod +r /etc/group zou dit op moeten lossen.

[VelhaChica]

Ik heb de rechten goedgezet. Het maakt geen verschil. Deze server draait als Xen bij Netland. Ik kan niet simpel wat recovertruukjes toepassen. Alles mag keihard op de command line. Zowel /etc/group, als /etc/passwd zien er goed uit. Volgens mij moet ik het dieper zoeken in het systeem.

Edit:

Het lijkt erop dat de PAM kapot is. Kan dit?

[ Voor 8% gewijzigd door VelhaChica op 17-02-2007 21:23 ]

[terabyte]

VelhaChica schreef op zaterdag 17 februari 2007 @ 21:11:
Het lijkt erop dat de PAM kapot is. Kan dit?

PAM gaat niet 'zomaar' kapot. Je hebt iets gedaan met /etc/group dus je moet je daarop richten, lijkt me.
En heb je al geprobeerd het origineel terug te zetten?

[benoni]

Als je in /etc/group handmatig een groep toevoegt of weghaalt, lijkt me dat je 't voor dezelfde groep ook in /etc/gshadow moet aanpassen. Heb je dit gedaan?

Zoniet, dan is het slim om /etc/group en /etc/gshadow naast elkaar open te zetten, dan heb je waarschijnlijk genoeg overzicht om de 'schade' in /etc/group te herstellen.

Voorbeeldregel /etc/group:

code:

users:x:100:user1,user2,user3

^ genoemde users moeten zijn terug te vinden in /etc/passwd en /etc/shadow

Bijbehorende regel /etc/gshadow:

code:

users:*::user1,user2,user3

[VelhaChica]

Hierbij zet ik mijn config files hier neer. Als eerste staat hier mijn /etc/group. Ik kan daar weinig raars in ontdekken.

root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon,lp
mem:x:8:
kmem:x:9:
wheel:x:10:root
mail:x:12:mail,exim,postfix
news:x:13:news
uucp:x:14:uucp
man:x:15:
games:x:20:
gopher:x:30:
dip:x:40:
ftp:x:50:
lock:x:54:
nobody:x:99:
users:x:100:web8_stoopmanm,web8_barkhuist,web8_cornelisseno,web8_driemf,web8_boutkand,web8_lindemane,web8_bemmell,web8_koopmand,web8_evanr,web8_wg02,web8_wg01,web8_info,web8_voorzitter,web8_wg03,web8_secretaris,web8_penningmeester,web8_secretariaat,web8_wg04,web8_bestuur,web8_hellemannm
dbus:x:81:
nscd:x:28:
floppy:x:19:
vcsa:x:69:
netdump:x:34:
pcap:x:77:
utmp:x:22:
slocate:x:21:
mailnull:x:47:
smmsp:x:51:
haldaemon:x:68:
rpc:x:32:
named:x:25:
sshd:x:74:
rpcuser:x:29:
nfsnobody:x:65534:
upwatch:x:78:
ntp:x:38:
rpm:x:37:
apache:x:48:
exim:x:93:
postdrop:x:90:
postfix:x:89:
xfs:x:43:
webalizer:x:67:
admin:x:500:
admispconfig:x:501:admispconfig
dovecot:x:97:
mysql:x:27:
web7:x:10007:admispconfig,web7_main
web8:x:10008:admispconfig,web8_main
mailman:x:41:
web11:x:10011:admispconfig
backup:x:101:

Hieronder staat de /etc/gshadow. Volgens mij horen die uitroeptekens daar helemaal niet.

root:::root
bin:::root,bin,daemon
daemon:::root,bin,daemon
sys:::root,bin,adm
adm:::root,adm,daemon
tty:::
disk:::root
lp:::daemon,lp
mem:::
kmem:::
wheel:::root
mail:::mail,exim,postfix
news:::news
uucp:::uucp
man:::
games:::
gopher:::
dip:::
ftp:::
lock:::
nobody:::
users:::web8_stoopmanm,web8_barkhuist,web8_cornelisseno,web8_driemf,web8_boutkand,web8_lindemane,web8_bemmell,web8_koopmand,web8_evanr,web8_wg02,web8_wg01,web8_info,web8_voorzitter,web8_wg03,web8_secretaris,web8_penningmeester,web8_secretariaat,web8_wg04,web8_bestuur,web8_hellemannm
dbus:x::
nscd:x::
floppy:x::
vcsa:x::
netdump:x::
pcap:x::
utmp:x::
slocate:x::
mailnull:x::
smmsp:x::
haldaemon:x::
rpc:x::
named:x::
sshd:x::
rpcuser:x::
nfsnobody:x::
upwatch:!::
ntp:!::
rpm:!::
apache:!::
exim:!::
postdrop:!::
postfix:!::
xfs:!::
webalizer:!::
admin:!::
admispconfig:x::admispconfig
dovecot:!::
mysql:!::
web7:x::admispconfig,web7_main
web8:x::admispconfig,web8_main
mailman:!::
web11:x::admispconfig
backup:!::

[benoni]

VelhaChica schreef op zondag 18 februari 2007 @ 23:28:
Volgens mij horen die uitroeptekens daar helemaal niet.

Dat is normaal, omdat er geen password login via de groepnaam gegeven wordt:

code:

~# man gshadow
...
If the password field contains some string that is not valid result of crypt(3),
for instance ! or *, the user will not be able to use a unix password to log in,
subject to pam(7).
...

Ik zie verder ook niets schokkends in je /etc/group en /etc/gshadow.
Kun je anders even op een simpele manier inloggen als een normale gebruiker (met 'su <gebruikersnaam>', of met ssh of ftp) en kijken wat PAM doet ('tail /var/log/auth.log' in de root terminal)?

edit:
'tail /var/log/auth.log' moet je misschien aanpassen voor RedHat als de auth logfile in een andere directory wordt geschreven

[ Voor 8% gewijzigd door benoni op 19-02-2007 00:18 ]

[VelhaChica]

Ik heb zelf contact gehad met mijn leverancier. Zij hebben het er over dat het passwd bestand corrupt is geraakt. En het shadow passwd bestand (???) ook. Is het mogelijk om dit te herstellen? De rechten lijken dus helemaal in puin te liggen.

[igmar]

Wat zegt

code:

ls -ld /tmp
ls -ld /var/lib/mysql 
id mysql

?

[zAo]

Ik ben meer benieuwd naar de rechten van root:

code:

 ls -ld /

Aangezien dit in de melding voorkomt:

httpd error.log [Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to / denied

Deze moet op 775 root:root (of bin:bin) staan.

[benoni]

VelhaChica schreef op maandag 19 februari 2007 @ 14:32:
Ik heb zelf contact gehad met mijn leverancier. Zij hebben het er over dat het passwd bestand corrupt is geraakt. En het shadow passwd bestand (???) ook. Is het mogelijk om dit te herstellen?

Ja, en dat mag ook met je eigen favoriete text editor, want het zijn gewoon simpele ASCII-tekstbestanden met Unix regeleinden. Dus je kunt gewoon een nieuw wachtwoorden bestand klaarmaken (/etc/passwd-new) en daarna bestanden omwisselen door de namen aan te passen (bijvoorbeeld zo in de root terminal):

# Neem de bestaande toegangsrechten over naar het nieuwe bestand:
chmod --reference=/etc/passwd /etc/passwd-new
chown --reference=/etc/passwd /etc/passwd-new

# Wissel de bestanden om:
mv /etc/passwd /etc/passwd-old; mv /etc/passwd-new /etc/passwd

Maar probeer eerst even de adviezen uit de bovenstaande posts, wie weet zit de fout in een ander hoekje.

[VelhaChica]

DIt is de root.

drw-rw-r--  21 root root 4096 2007-01-17 17:07 /

Ik zit net te bedenken. Ik heb per ongeluk

chmod -R 664 /

gedaan. Kan dit alles verklaren? Dit haal ik uit het .bash-bestand.

[skr]

Doe dan maar een reinstall...Kan je denk niet zomaar weer herstellen

en schaam je niet, ik heb in mijn 4jaar linux tijd al 2x dit soort fratsen uitgehaald.

(1x initcpio image uitpacken als root op / en 1x # chown -R userr / )

[Jungian]

skr schreef op maandag 19 februari 2007 @ 22:16:
Doe dan maar een reinstall...Kan je denk niet zomaar weer herstellen

Poe hé. Wat rechten chmodden. Echt tijd voor een reinstall ja

[skr]

Jungian schreef op maandag 19 februari 2007 @ 22:19:
[...]

Poe hé. Wat rechten chmodden. Echt tijd voor een reinstall ja

Ja maar ik meen het dus echt serieus hoor

Nu zal het wel werken maar om alles in originele staat terug te zetten ben je echt lang bezig. Maar dat moet jij eigenlijk wel weten...

Tenzij er een apget --restore-mods ofzo bestaat

[Rainmaker]

VelhaChica schreef op zaterdag 17 februari 2007 @ 20:10:
070217 17:34:10 mysqld started
^G/usr/libexec/mysqld: Can't read dir of '/tmp/' (Errcode: 13)
^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ib5dwAJE' (Errcode: 13)
070217 17:34:10 InnoDB: Error: unable to create temporary file; errno: 13
070217 17:34:10 [ERROR] bdb: /var/lib/mysql: Permission denied
070217 17:34:10 [ERROR] bdb: /var/lib/mysql/log.0000000001: Permission denied
070217 17:34:10 [ERROR] bdb: PANIC: Permission denied
070217 17:34:10 [ERROR] bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
070217 17:34:10 [ERROR] bdb: fatal region error detected; run recovery
070217 17:34:10 [ERROR] bdb: /var/lib/mysql: Permission denied
070217 17:34:10 [ERROR] Can't start server : Bind on unix socket: Permission denied
070217 17:34:10 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
070217 17:34:10 [ERROR] Aborting

070217 17:34:10 [Note] /usr/libexec/mysqld: Shutdown complete

070217 17:34:10 mysqld ended

• dovecot

Feb 17 17:15:23 coc2 dovecot: imap-login: Login: user=<web8_wg04>, method=plain, rip=::ffff:145.116.9.155, lip=::ffff:217.170.53.62
Feb 17 17:15:24 coc2 dovecot: child 1828 (imap) returned error 89
Feb 17 17:15:27 coc2 dovecot: chdir(/var/www/web8/user/web8_wg04) failed with uid 10034: Permission denied

• httpd

error.log

[Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to / denied
[Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /error/forbidden.html denied
[Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /favicon.ico denied
[Sat Feb 17 19:39:32 2007] [error] [client 145.116.9.155] (13)Permission denied: access to /error/forbidden.html denied

• proftpd
• sshd
[/list]

Als je echt AL je rechten ver*t hebt, is het inderdaad lastig om het weer recht te trekken.

In ieder geval:

1. Mysql;
chmod -R 777 /tmp
chown -R mysql:mysql /var/ilb/mysql

2. Dovecot;
Ken ik niet. Waarschijnlijk iets op /var/www/web8/user/web8_wg04

3. Apache;
chmod 775 <jouw httpd root>
chown apache:apache <httpd root>

[benoni]

skr schreef op maandag 19 februari 2007 @ 22:16:
Doe dan maar een reinstall...Kan je denk niet zomaar weer herstellen

MacOSX heeft zo'n rechtenherstel tooltje standaard op de rescue DVD staan zou die ook op Linux werken?

Stel dat het echt een hoop tijd nodig heeft om te herinstalleren... TS, heb je meerdere servers in het netwerk met dezelfde indeling? Dan kunnen we wel een recursief paardemiddeltje verzinnen die de rechten van het 'gezonde' systeem netjes overneemt naar het 'zieke' systeem...

[igmar]

VelhaChica schreef op maandag 19 februari 2007 @ 22:09:
Ik heb per ongeluk

chmod -R 664 /

gedaan. Kan dit alles verklaren? Dit haal ik uit het .bash-bestand.

Zo'n vermoeden had ik al. Je zal of een tool moeten zoeken die de permissions van je systeem restored (voor zowel RPM als dpkg zijn daar tools voor), of een herinstall doen.

Voor RPM kun je het volgende proberen :

code:

rpm -qa --queryformat "%{NAME}\n" | xargs --max-lines=1 rpm --setperms

[ Voor 14% gewijzigd door igmar op 20-02-2007 08:41 ]

[VelhaChica]

Helaas heeft de patiënt zijn laatste adem uitgeademd. Soms moet ik maar niet op de knopjes willen drukken. In ieder geval wordt iedereen bedankt voor zijn hulp. Ik heb het systeem opnieuw geïnstalleerd. Dat werkte sneller dan moeten uitzoeken waarom bepaalde zaken niet meer werkte.