pam_tty_audit icanon log switch

[Richard Guy Briggs]

On Mon, Apr 22, 2013 at 02:29:09PM -0400, Richard Guy Briggs wrote:
> On Mon, Apr 22, 2013 at 01:28:05PM -0400, Miloslav Trmač wrote:
> > ----- Original Message -----
> > > On Thu, Apr 18, 2013 at 04:07:08PM -0400, Richard Guy Briggs wrote:
> > > > On Thu, Apr 18, 2013 at 03:31:36PM -0400, Miloslav Trmač wrote:
> > > > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > > > > index 9f096f1..a863669 100644
> > > > > > --- a/include/uapi/linux/audit.h
> > > > > > +++ b/include/uapi/linux/audit.h
> > > > > > @@ -369,7 +369,8 @@ struct audit_status {
> > > > > >  };
> > > > > >  
> > > > > >  struct audit_tty_status {
> > > > > > -	__u32		enabled; /* 1 = enabled, 0 = disabled */
> > > > > > +	__u32		enabled;	/* 1 = enabled, 0 = disabled */
> > > > > > +	__u32		log_icanon;	/* 1 = enabled, 0 = disabled */
> > > > > >  };
> > > > > 
> > > > > Also, would it make sense for the user-space API to be more general
> > > > > about expressing the intent ("log passwords")?  I don't know, being
> > > > > precise about the exact effect of the option is also beneficial.
> > > > 
> > > > Hmmm, I'll have to ponder that...
> > > 
> > > I am inclined to leave it named as is for precision.
> > 
> > I suggested it might be better to change the name because with (icanon
> > & !echo) being the discriminator, "log_icanon" is no longer precise.
> 
> Good point.  I was one thought behind...
> 
> > I can't think of an identifier that is both precise and understandable
> > - neither log_icanon_noecho or log_passwords are the obvious
> > possibilities, neither makes me enthusiastic.
> 
> Of these, I prefer log_passwords.
> 
> > Perhaps it doesn't matter that much what the audit_tty_status member
> > is called - that's an implementation aspect and anybody touching this
> > needs to understand the precise effects regardless of the name of the
> > member.  The pam_tty_audit option name is user-visible and should be
> > easy to understand and use.  (I'm not sure changing the topic like
> > this is an improvement - it seems natural to use the same name for
> > both, and even the users may need to understand the implications of
> > icanon & !echo; I'm just hoping this might lead to better
> > suggestions.)
> 
> Given the original intent, and the user-visible effects, I'd lean to
> log_passwords, and let the kernel implement the details necessary to
> carry out that intent.

Shall I go ahead and spin a new patch that replaces most uses of
"log_icanon" with "log_pw" or "log_passwords"?

The kernel and pam_tty_audit patches are otherwise ready.  I got the
autoconf bits working.

I've not heard from Eric Paris if I've addressed the userspace structure
versioning concerns adequately.

> >     Mirek
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs at redhat.com>
> Senior Software Engineer
> AMER ENG Base Operating Systems
> Remote, Canada, Ottawa
> Voice: 1.647.777.2635
> Internal: (81) 32635
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rbriggs at redhat.com>
Senior Software Engineer
AMER ENG Base Operating Systems
Remote, Canada, Ottawa
Voice: 1.647.777.2635
Internal: (81) 32635