[ubuntu] su/pam probleem

[ajvdvegt]

Ik heb in Ubuntu (Dapper Drake) Tomcat 5.5 (en later ook 5) geinstalleerd. De installatie ging niet vlekkeloos, maar na wat tips uit de Ubuntu forums zijn de eerste problemen opgelost (JDK niet gevonden bv).

ik loop nu echter tegen een schijnbaar nieuw probleem aan wat waarschijnlijk los staat van Tomcat, maar zich nu voor het eerst openbaart. Als ik (als root) iets wil opstarten als de gebruiker 'tomcat5' geeft su een foutmelding. Deze opdracht bv:

code:

su -c xterm tomcat5

Geeft (net als elke andere soortgelijke opdracht) deze foutmelding:

code:

su: Cannot make/remove an entry for the specified session

De gebruiker 'tomcat5' is uiteraard speciaal gemaakt om tomcat te starten. Onlangs heb ik ook postgresql geinstalleerd, waarvoor ook een nieuwe gebruiker werd aangemaakt. Toen ik ter controle die gebruiker wilde gebruiken om een programma te starten, ging dat de eerste keer goed. De tweede keer kreeg ik echter weer bovenstaande foutmelding.

Google helpt niet echt, ik kom alleen uit bij documentatie die zegt *dat* deze melding kan komen, en niet waarom. Het blijkt trouwens dat PAM de melding geeft; su presenteert 'm alleen maar op de commandline. Heeft iemand enig idee wat de oorzaak van deze melding kan zijn?

[deadinspace]

Krijg je dezelfde melding als je zo probeert te su-en naar andere gebruikers, zoals bv man, bin, of je eigen user?

(om te testen is het misschien handiger om het command id te gebruiken ipv xterm)

[mithras]

Kan je uberhaupt wel su'en?

su tomcat5

Werkt dat wel (en dan inloggen met tomcat5 password). Ik ken tomcat niet, maar je kan ook met sudo su'en:

sudo su tomcat5

Dan kan je je eigen password invoeren voor sudo en met root rechten hoef je geen password in te voeren voor su. Moet je wel sudo rechten hebben natuurlijk, maar als standaard Ubuntu gebruiker heb je die wel.

[ajvdvegt]

@Deadinspace:
Voor die gebruikers geldt hetzelfde: de eerste keer gaat het goed, daarna krijg ik bovenstaande foutmelding. En id is inderdaad wel handiger ja . Na een reboot werkt het weer 1 keer gelukkig.
@Mithras:
De gebruiker tomcat5 heeft geen wachtwoord, hij is enkel bedoeld om via 'su' tomcat te starten. Als ik root ben en dan 'sudo su tomcat5' gebruik, krijg ik ook bovenstaande foutmelding .

[deadinspace]

Ehm, in dat geval zou ik graag eens een strace output zien...
Zou je direct na het booten (zodat de eerste su goed gaat) eens

code:

strace -o su-ok.strace su -c id tomcat
strace -o su-fail.strace su -c id tomcat

willen doen, en dan su-*.strace ergens online willen zetten oid? (ze zijn mogelijk wat groot om hier te posten)

[ajvdvegt]

Best nuttig inderdaad, die straces... ze staan hier en resp. hier. (voor de gebruiker postgres, die van tomcat5 was alweer stuk) (Voor de nieuwsgierige lezer: SVP alleen downloaden als je hier bekent mee bent, ik heb een 10MB/dag bandbreedte limiet, en dat trek je makkelijk vol via GoT, heb ik al eens gemertk.....)

Voorzover ik er zelf wijs uit kan worden gaat het mis omdat er na de eerste opdracht een lock bestandje is aangemaakt in /var/run/console/ (rechten 644, owner: root:<user>). Na het verwijderen van dat bestand kan ik weer 1 keertje su'en, whooah!

Met die map kan ik zelf misschien al meer info vinden, het is nu alleen bedtijd. Komend weekend moet ik zeker ergens tijd hebben om dit te debuggen. Uiteraard sta ik tot die tijd open voor tips, maar sowieso al bedankt voor de strace tip!

[deadinspace]

Inderdaad

Voor de geinteresseerden, uit su-fail.strace:

code:

open("/var/run/console/postgres:7", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EEXIST (File exists)
...
write(2, "su: Cannot make/remove an entry "..., 58) = 58
...
exit_group(1)                           = ?

Maar als ik dan in su-ok.strace kijk:

code:

open("/var/run/console/postgres:7", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
close(4)                                = 0
getuid32()                              = 0
getuid32()                              = 0
time(NULL)                              = 1179266864
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
send(3, "<38>May 16 00:07:44 su[11685]: ("..., 85, MSG_NOSIGNAL) = 85
setuid32(119)                           = 0
close(3)                                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fe3ba8) = 11686
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], NULL, 8) = 0
rt_sigaction(SIGTERM, {0x8049a70, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [ALRM TERM], NULL, 8) = 0
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED) = 11686
unlink("/var/run/console/postgres:7")   = -1 EACCES (Permission denied)

Dan zie ik op regel 1 dat hij die lockfile aanmaakt, en op regel 17 probeert hij die op te ruimen, maar dat faalt. Interessant is daarbij dat hij op regel 10 switcht naar uid 119.

Dus, zou je eens

grep 119 /etc/passwd
ls -ld /var/run/console

kunnen doen? Ik denk dat uid 119 postgres is, en dat die geen schrijfrechten heeft in /var/run/console.

[ajvdvegt]

Tsss...ik voel me bijna detective op m'n eigen systeem

Doe je dit vaker ofzo?Je hebt namelijk helemaal gelijk! 119 IS postgres, en alleen root heeft schrijfrechten in /var/run/console (owner: root:nogroup, rechten 755). Ik ga even naar een Live CD booten om te kijken wat de rechten horen te zijn. Bedankt!

[ajvdvegt]

ok, het werkt allemaal weer! Het lag niet direct aan de rechten op de map, maar aan mijn pogingen om jaren geleden eens een versleutelde directory te maken. 'common-pammount' gooide waarschijnlijk roet in het eten. Ik heb daar 'use_first_pass' uitgecommentarieerd, en alles werkt weer zoals 't hoort.

[deadinspace]

ajvdvegt schreef op woensdag 16 mei 2007 @ 22:38:
Tsss...ik voel me bijna detective op m'n eigen systeem

Leuk he... Met de juiste tooltjes, wat kennis, en eventueel de source van de programma's in kwestie kun je een heel eind komen

Doe je dit vaker ofzo?

Ehh, ja

Je hebt namelijk helemaal gelijk! 119 IS postgres, en alleen root heeft schrijfrechten in /var/run/console (owner: root:nogroup, rechten 755).

Nouja, je su-de naar postgres, dus dan is het logisch dat su uiteindelijk een setuid() doet naar postgres' uid. Dus dat 119 postgres was was geen duister visioen van mij ofzo

En dat de permissies op /var/run/console zo waren dat posgres er niet in mag schrijven wordt natuurlijk verraden door de unlink() die EACCESS krijgt.

Ik ga even naar een Live CD booten om te kijken wat de rechten horen te zijn.

Ah, een Live CD (van Ubuntu dan wel bij voorkeur), dat is een goed plan! Ik vraag me namelijk nog wel af hoe dat op te lossen, want ik kan zo geen permissies bedenken waarmee dit wel gaat werken (los van simpel world-writable, maar dat lijkt me niet wenselijk).

Als je toch met die livecd bezig bent, controleer dan even of su daar wel normaal werkt, en maak er ook even een strace van

Bedankt!

Graag gedaan hoor.

edit:
En oh