[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: tty events



Hello,
----- "Robert Daniels" <robertdaniels2009 gmail com> wrote:
> I'm using pam_tty_audit and am collecting specific users, including root.
>
> When logged in as root, the tty events are sent to the plugin in near real-time.
> However, when logged in as a user, the events are cached someplace and are eventually flushed to the dispatcher/plugin.
> The other odd thing is the cached user events are in a single event, and is a collection of multiple tty commands stored into one chunk of data.
> I've looked at the source code but do not see where this caching takes place.
For "raw mode" TTYs (e.g. the bash command-line editing environment, vi), newline is not a reliable "command" indicator, so the keystrokes are queued until the buffer (which is 4096 bytes) is full.

Programs that accept something like "commands" should send USER_TTY records whenever a "command" is entered; this also flushes the buffer, creating the TTY record containing keystrokes to that point.  If I remember correctly, this is implemented for bash and programs that use the readline library.

The problem is that only programs running as root are allowed to send audit records from user-space, so the USER_TTY records sent from unprivileged programs are ignored and do not flush the buffer.

> I'd like to know if there is a setting to disable this caching and send the events in real time, or at least have a way to break these events up, and acquire a timestamp that matches when the events took place.
I'm afraid there isn't currently a practical way to do this.  (bash --noediting) does not use the raw mode, but I'd hardly consider that practical.
    Mirek



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]