gdm : bad username

[visinet]

Hi guys,

I have just built a grsec box with oracle (don't laugh) and went through a series issues getting it running.
I've gotten over most of the newbie issues involving XFree86 with chpax'ing the binary, and also found XFree failed to start whenever I had denied writes to /dev/kmem.

I finally got Perl's DBD::Oracle working with a chpax -m on httpd.

Anyway, I still have a problem starting X. With grsec enabled, I have the following logged:

gdm(pam_unix)[11153]: bad username []

Quite regularly. gdm fails to start, and when my machine starts up, I only see the background and an egg timer cursor.

Any assistance appreciated.

I have disabled all RBAC.

[visinet]

This was resolved with a chpax -rms /usr/bin/gdmgreeter (being the program that checks your password, and apparently returns null when it crashes)

I am wondering though, since nothing was present in the logs indicating it was killed by PaX, am I missing somethign?

[PaX Team]

This was resolved with a chpax -rms /usr/bin/gdmgreeter (being the program that checks your password, and apparently returns null when it crashes)

I am wondering though, since nothing was present in the logs indicating it was killed by PaX, am I missing somethign?

did you have PAGEEXEC enabled in your kernel .config? if PaX didn't log anything then it's most likely randomization that caused the problem, try to disable only that and see if it still works (that's not to say i'd know why randomization causes such a failure, it'll be another debugging session for someone with enough free time...). as for the -m on apache, just for my curiosity can you give me the PaX kill logs that you got with that DBD::Oracle module?

[visinet]

As for the first question:

# CONFIG_PAX_PAGEEXEC is not set

You are correct, it does appear to be the randomisation for gdmgreeter.

I don't appear to have any PaX kill logs for httpd, again, I'm not sure why this would be, I ran a few greps and only found my Xorg from before I fixed it.

Just to throw you another curve ball, oracle terminates with:
ORA-27123: unable to attach to shared memory segment

Without logging anything.
I fixed this with just :
chpax -s oracle

I'm suspecting I have a logging problem going on here.

[PaX Team]

I don't appear to have any PaX kill logs for httpd, again, I'm not sure why this would be ...

-m allows an app to generate code at runtime, that's why i thought that apache (or more likely, some module loaded into it) attempted that and got killed. if that's not the case then i can't imagine how -m would fix your problem . next you said:

Just to throw you another curve ball, oracle terminates with:
ORA-27123: unable to attach to shared memory segment

Without logging anything.
I fixed this with just :
chpax -s oracle

does this mean that you need chpax -m apache *and* chpax -s oracle to solve your problem? in any case, i'd really like to see a full strace -f of apache/perl/oracle (whatever is involved, i don't know how these interact in your setup) if possible.

[visinet]

[/quote]does this mean that you need chpax -m apache *and* chpax -s oracle to solve your problem? in any case, i'd really like to see a full strace -f of apache/perl/oracle (whatever is involved, i don't know how hese interact in your setup) if possible.[/quote]

Apologies for the delay, we had many unrelated server issues.

Yes and no.
Oracle fails to start, at all, without a chpax -s. It just dumps that message to desktop, and quits.

Apache, which starts later, works fine, until you try to run a particular CGI script, (calling DBD::Oracle) at which point, you get perl dumping the error.

I also can't imagine how the -m fixes the first problem, all I can think of is that I have some logging problem preventing me from seeing something get killed. I'll run some checks with paxtest and see what I find.

Oracle is just as confusing, as without the -s, it doesn't actually get killed. In fact, according to its log, it has done a graceful shutdown, due to being "unable to attach to shared memory". All confusing I know. Oracle is firewalled from the outside world and the only interface is my perl script, so I can live with the -s if I have to (and I assume I do).

[visinet]

Oh, just to follow up, if you want an strace of anything after reading the above, please let me know.

[PaX Team]

Oh, just to follow up, if you want an strace of anything after reading the above, please let me know.

yes please, first oracle (both working/non-working cases, former you can terminate once you see it got past the failure point of the non-working case), then apache, again in both the working/non-working cases. disable randomization for all tests, it makes address correlation easier. as for the logs, best is if you can put them online somewhere, or if they're a few megs only, email them directly to me. also, if they contain sensitive info to your setup, encrypt them.