I should have read my mail in better sequence... ;) Well, I think this basically covers what we are looking for - doesn't it. This, together with Marcus Logging Map (and a little tweaking) could do well. Sure, sure already a number of comments out there on the list, but wouldn't it an idea for others to join this development? I had just roughly 20 minutes with the lib, but it looks well to me... The only problem I see (as one of these old-style closed source guys...) is that we can't use it in our projects because of GPL. The same will be true for others, I fear... Any chance for a change to LGPL if we decide to move into that direction? I am getting more and more the impression that all resources are already out there, we "just" need to get a grip on which to use and... DO THAT. Loganalysis.org could be a great place to drive this... Rainer > -----Original Message----- > From: marc [mailto:marcat_private] > Sent: Thursday, January 02, 2003 10:39 PM > To: Marcus J. Ranum > Cc: avalonat_private; bazsiat_private; > loganalysisat_private > Subject: Re: [logs] Syslog payload format > > > You wrote: > > Aaaaah. Now I understand what you meant. You want to be > > able to have the API do input conversion. I still think > that'll make > > the API much more complex than it needs to be. For example, > it'll have > > to "know" how to convert a struct sockaddr_in into a > string, etc, etc. > > Even if the application calling it doesn't need to know how to do > > that. That's why apps are so bloated these days. :) It might > > be a good idea to include some ultralight helpers around > > the underlying API, which is easy enough if you use a > > structure like: > > EventRec *newev; > > > > newev = eventlog_new(); > > eventlog_addvalue(newev,EVENTLOG_PATH,pathname); > > eventlog_addvalue(newev,EVENTLOG_PRIO,"4"); > > > > you can make the helpers do the conversion and then you're > leaving it > > easy to add new helpers as needed, i.e.: > > eventlog_addvalue_ipaddr(newev,EVENTLOG_SRCIP,(struct sockaddr_in > > *)src); eventlog_addvalue_int(newev,EVENTLOG_PRIO,4); > > > > This is not hard. :) > > Indeed ;) A very similar API (modulo typing) has existed > for close on two years. Quoted without any modification from > > http://jade.cs.uct.ac.za/idsa/download/idsa-0.93.8.tar.gz > > in idsa-0.93.8/pam/pam_idsa.c (which has existed without > major change for over a year): > > ev = idsa_event(cn); > if (ev) { > idsa_name(ev, "authenticate"); > idsa_scheme(ev, IDSA_PAM_SCHEME); > > idsa_risks(ev, 1, arisk, crisk, irisk); > idsa_add_string(ev, "pam_user", (char *) pam_user); > idsa_add_set(ev, "pam_uid", IDSA_T_UID, &(pwd->pw_uid)); > > if (pam_rhost != NULL) { > idsa_add_string(ev, "pam_source", "pam_rhost"); > idsa_add_scan(ev, "pam_rhost", IDSA_T_HOST, pam_rhost); > } else if (pam_tty != NULL) { > idsa_add_string(ev, "pam_source", "pam_tty"); > idsa_add_string(ev, "pam_tty", pam_tty); > } else { > idsa_add_string(ev, "pam_source", "pam_none"); > } > > if (idsa_log(cn, ev) == IDSA_L_ALLOW) { > result = PAM_SUCCESS; > } else { > result = PAM_AUTH_ERR; > } > } else { > result = failopen ? PAM_IGNORE : PAM_ABORT; > } > > It is actually pretty similar, and your proposed code should > compile with the following defines: > > #define EventRec IDSA_EVENT > #define eventlog_new() idsa_event(connection) > #define eventlog_addvalue idsa_add_string > #define eventlog_addvalue_int idsa_add_integer > IDSA_CONNECTION *connection; > connection = idsa_open("foo", NULL, 0); > > This is also the API on top of which I have built the > single-line idsa_set function call. Eg assuming that pam_tty > was always valid the above could be written as: > > if(idsa_set(cn, "authenticate", IDSA_PAM_SCHEME, 1, arisk, > crisk, irisk > "pam_user", IDSA_T_STRING, pam_user, > "pam_uid", IDSA_T_UID, &(pwd->pw_uid), > "pam_source", IDSA_T_STRING, "pam_tty", > "pam_tty", IDSA_T_STRING, pam_tty, > NULL) == IDSA_L_ALLOW){ > result = PAM_SUCCESS; > } else { > result = PAM_AUTH_ERR; > } > > As a matter of fact since the beginning of this week it > has (disabled/half implemented) code to pull data out of > a generic sockaddr too ;) > > regards > > marc > _______________________________________________ > LogAnalysis mailing list > LogAnalysisat_private > http://lists.shmoo.com/mailman/listinfo/logana> lysis > _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:58:05 PST