Linda Walsh wrote:
I'm trying to debug a core-dump prob, but, if I am certain that I get all the config options 'right', maybe the coredump will disappear...
It was a bad SECURITY configuration, after-all...*sigh*. (Not that I'd disagree with the default settings for most people -- but most people aren't forward-porting a server config that's been working (and ported forward with version changes) since SuSE 7.0 (~2000-2001). One of the important config options that I didn't even know was turned on was causing the problems. After I fixed my 'ntp' problem my sockd problem went away as well -- no more coredumping. Essentially my kernel had a bit of extra "security" in it that was turned on and "silently" biting some of my services in the posterior. I say silently, only because my 'standard' bit of looking for common messages (unless I know I put them in another directory, almost exclusively for sake of permissions (i.e. so a subdir can have matching user:group ownership to allow writeability ownership by non-root daemons)) involves: "ls -rt /var/log" and looking for what files have recently changed (within some period of interest). When I see no err's in recent log files, I assume things are good unless it's a log for a non-root daemon. Got suckered by 'audit.log' being in it's own 'audit' subdirectory for no _apparent_ reason (owned by root.root)? But wouldn't have really helped anyway, as I knew I didn't want or need auditing just yet and had turned auditing off. Also, AFAIK, auditing was limited in its functionality, anyway -- or used to be. Reminiscing: Some years ago, I tried to explain why I wanted certain auditing hooks in file-access routines, only to be told I didn't know what I was talking about. I wanted to have discretionary permissions checked before mandatory permission checks (mandatory, being administrative-file-permissions that weren't changeable at the discretion of a non-admin (non-root) user -- like 'ext2/3/4', append-only and immutable flags. If a user was 'shut-out' by discretionary flags (i.e. file not writeable as decided by the file mode bigs (user,group,other), then I didn't care. But if the user somehow got write-access to the file (became root, or was in group w/group write, or other-got set to +w), and THEN they tried 'illegally' access such a file (immutable or append-only), then I wanted to have it 'audited' or 'logged'. I was told my requirements were unrealistic and that I was just asking for "too much" and I should be happy w/whatever bones were tossed my way. At that point, I realized the people I was dealing had their own preconceptions of 'security' that didn't jive with mine (in fact, for a long time, 'auditing' wasn't considered any part of 'security', nor any reason to add hooks to the LSM security set -- and if I couldn't come up with a 'real security policy', that didn't involve 'auditing', to justify the hooks I wanted, then forget it. But...that was years ago (8-9 years ago). Ancient history...:-) Anyway, I think AppArmor might explain some of my other oddities -- but shouldn't jump to conclusions. AppArmor (or some other mandatory security policies) would likely be good to add at some point (but just trying to get things working again first). My 'server' is mostly serving internal networks only, at this point, so my security-setup doesn't mandate something like AppArmor, just yet...:-) I hadn't realized how badly 'apparmor' interfered with configuring services that were already working. Maybe if the services hadn't been working in the first place, I wouldn't have gotten the hint about several unexplained problems.... But the following seems to have fixed most of the broken service problems I was having:
chkconfig boot.apparmor off /etc/rc.d/boot.apparmor stop
Oh well... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org