On Wed, Nov 11, 2009 at 02:43:17PM -0800, Rob Johnston wrote: > Nicolas Williams wrote: > >On the phone you characterized this debug log as a private interface. > >Is that right? > > Yes - it's private and disabled by default. > > >To me that seems like a poor reason to complicate > >process credentials setup of the daemon, though there's nothing fatally > >wrong with doing that. For a private debug logging facility I'd just > >make the daemon take SIGUSR1/2 to enable/disable debug logging to > >syslog, and be done. > > Yes, good point - and this seems like a reasonable way to go. I will make > this change.
OK. That simplifies things a bit. > >As for core dumping... > > > >Why should a service set its process core pattern? Why not use global > >coreadm settings? That seems like an architecturally significant > >detail. > > This is how fmd(1m) has always behaved (it sets it's core pattern to drop > it's cores in /var/fm/fmd/), so there's precedence for this. From > experience looking at a lot of fmd issues on customer systems, it has > helped us to know where the fmd cores are going to be and to know that all > of the fmd cores have been preserved and not overwritten. Based on that > we'd like snmp-notify and smtp-notify to behave in a similar fashion. Interesting. If this is something that we want to do there must also be a better way to do this... I find it odd that this choice should force daemons to run with euid == 0. For example, we could have a directory, say, /var/core/noaccess/ owned by noaccess (or perhaps with write perms for the noaccess group) into which such daemons could drop core. fmd may need privileges and euid==0 for other reasons -- such daemons should not drop core in a directory that noaccess can write to. Nico --
