Re: pam_tty_audit icanon log switch

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.

> Mirek - RGB -- Richard Guy Briggs <rbriggs(a)redhat.com&gt; 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(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit