>Number:         167321
>Category:       kern
>Synopsis:       Implement sysctl to control kernel accounting log messages 
>(e.g. acct(2))
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 26 11:40:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 8.2-STABLE amd64
>Organization:
>Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10 
17:43:50 PST 2012 
[email protected]:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
>Description:
        The periodic script daily/310.accounting results in accounting
        being fully stopped then fully started every day.  This causes
        the message "Accounting disabled" followed by "Accounting enabled"
        being printed on the console (syslog level kern.notice).

        This happens because daily/310.accounting calls /etc/rc.d/accounting
        with the argument rotate_log.  This function quite literally calls
        /usr/sbin/accton twice.  See accounting_rotate_log() (read it slowly)
        to see what's going on.

        The messages comes from src/sys/kern/kern_acct.c, where
        log(LOG_NOTICE, "...") is called every time accounting is toggled
        via the acct(2) syscall (accomplished via accton(8)).

        The end result is a kernel message buffer that will eventually
        be filled with the above two messages.  This is extremely annoying,
        and unecessary for something like accounting log rotation.

        We wanted to use accounting (mainly for tracking disk I/O on a
        per-user and per-process level), but because of this problem, we
        had to cease use of it.
>How-To-Repeat:
        1. Set accounting_enabled="yes" in /etc/rc.conf
        2. Start accounting via "/etc/rc.d/accounting start"
        3. Look at "dmesg" or /var/log/messages
        4. Run /etc/periodic/daily/310.accounting
        5. Look at "dmesg" or /var/log/messages
>Fix:
        There's a couple ways to fix this, but I'm of the opinion this is
        the best choice with the least breakage:

        Implement a sysctl called kern.acct_logging which would control
        whether or not the log() statements are called.  1=enable logging,
        0=disable logging.  Default value would be 1 (to remain fully
        compatible with the existing model).

        Toggling this sysctl WOULD NOT result in any log() message being
        generated (i.e. no "Account logging disabled" message or similar),
        because if it did, we've solved absolutely nothing.

        Key point for those concerned about security ("wait, what if
        someone turns off logging?  Wouldn't you want to know that?"):
        acct(2) can only be called by root, and sysctls can only be
        modified by root.  An attacker who wanted to circumvent accounting
        would have to already have root.  Thus, the sysctl variable poses
        no security concern.

        If there are still somehow security concerns, then this could
        be made into a loader-adjustable-only tunable.

        I'd be happy to write the kernel code for this (it can't be that
        complex), but I would need someone senior to make sure it's
        safe/wouldn't cause problems.  The kernel is not my most familiar
        of playgrounds.
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"

Reply via email to