On Sun, Feb 13, 2011 at 8:45 PM, Philip Guenther <guent...@gmail.com> wrote: > On Sun, Feb 13, 2011 at 8:27 AM, Eric <airu...@gmail.com> wrote: >> On Sat, Feb 12, 2011 at 9:49 PM, Philip Guenther <guent...@gmail.com> wrote: > ... >>> Regarding the latter: if you're intending that this should affect all >>> programs without any changes to the program themselves, then this will >>> require much care and verification that it doesn't bloat everything. >>> Consider that *every* C program on OpenBSD pulls in syslog_r() to >>> support the stack-protector check code. If that starts pulling the >>> NIS code for getgrgid() to do the gid -> name mapping to find the >>> syslog socket, then many binaries will grow. That code would _have_ >>> to be excluded from the libc used in ramdisk builds! >> >> I can only think of two ways to avoid having NIS linked into everything: >> >> - Only use the modified syslog functions though LD_PRELOAD >> >> - Make openlog/syslog/closelog system calls (this would also allow >> us to ensure the accuracy of the pid and program name strings, and >> we could filter by program name in syslogd). > > Yow! Group names are strictly user-space right now; how exactly where > you planning on having the kernel get the group name for a process? > > Backing up a step, syslog_r() MUST remain async-signal-safe, so > whatever designs you ponder, please check them against that > requirement. That would be true even of an LD_PRELOAD replacement... > > > > Philip Guenther >
I've decided to stay in user-space and stick with group-based controls, but I've come across a small problem with modifying openlog to find the current process' group: Daemons like httpd perform openlog before they drop privileges, meaning that most daemons would end up logging to /dev/syslog_wheel/log. Not that this is such a horrible outcome, but it would be nice i these daemons logged to their own sockets. I'm not sure how to handle this problem, but I thought of two possible solutions: - It might be alright to have the group or perhaps the path of the log socket passed as part of the struct syslog_data that's explcitly provided by programs that use openlog_r/syslog_r. To get the daemons to use this option, we would have to modify each one to use the new struct member (many small changes). - I noticed that the syslog code uses connect() and send() to send messages to syslog. I could modify syslog to use sendto() instead--Would it be unreasonable to call getresgid and getgrgid for each call to syslog()? - If each process only had to call getresgid, would that help me avoid enlarging each process (avoiding NIS by not using getgrgid/getgrnam?) If I did this, I could use the gid_t instead of the group name as the path, e.g. /dev/syslog_123/log. Thanks for the help and ideas. - Eric
