Date: Thu, 26 Jul 2001 11:50:02 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: "Peter C. Lai" <sirmoo@cowbert.2y.net> Cc: "Jeroen Massar" <jeroen@unfix.org>, "'Garance A Drosihn'" <drosih@rpi.edu>, "'Matt Dillon'" <dillon@earth.backplane.com>, arch@FreeBSD.ORG, "'Garrett Wollman'" <wollman@khavrinen.lcs.mit.edu>, brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries Message-ID: <200107261850.f6QIoaa04255@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 25 Jul 2001 22:28:49 GMT." <20010725222849.17038.qmail@d170h113.resnet.uconn.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010725222849.17038.qmail@d170h113.resnet.uconn.edu>, "Peter C. La i" writes: > all true and good, but i think my issue was that suppose a 3rd party > application doesn't log correctly at all (in the case i mentioned, it could > be the shell's or pam's or sshd's fault (or some combination thereof) that > it does not regard HUPing a shell as a proper logout.). Changing the way > utmp/wtmp is recorded isn't going to change the data. However, i did say i > probably posted to the wrong thread, but it is still related to the issue of > erroneous data in lastlog. This brings to mind an example I experienced about a month ago after upgrading a Sun system to Solaris 8. The system has MIT Kerberos V. After the upgrade, /var/adm became a wasteland of some useless files (with strange names to boot). A recompile of the application failed to resolve the issue. As in the case of Solaris 8, all applications that write to utmp/wtmp & utmpx/wtmpx need to be aware of any changes, hence applications that once were portable are now not. It is my hope that we avoid the Solaris 8 type of mess when overhauling utmp/wtmp. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC > > Jeroen Massar writes: > > > Peter C. Lai <sirmoo@cowbert.2y.net> wrote: > > > > <SNIP> > >> > This is a spin-off of the thread in -security about: > >> > bin/22595: telnetd tricked into using arbitrary peer ip > > <SNIP> > >> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 > >> > > >> > > >> > At 10:07 AM -0700 7/23/01, Matt Dillon wrote: > >> >> Garrett Wollman wrote: > >> >> :<<On Mon, 23 Jul 2001, Matt Dillon said: > >> >> :> Garrett Wollman wrote: > >> >> :> : SVR4 has an API. This API is standardized as a part of > >> >> :> : the Austin Group process. > >> >> : > >> >> :> Fine.. then if you want to get all the third party program > >> >> :> authors to use a magic API, be my guest. > >> >> : > >> >> : If they run on Solaris -- which most of them do -- then > >> they already > >> >> : do. Nice try, Matt, but far off the mark. > >> >> : > >> >> :-GAWollman > >> >> > >> >> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me > >> >> to continue? > >> > > >> > Still... If there *is* an API which would be common to both Solaris > >> > and FreeBSD, then it should be much easier to get > >> third-party program > >> > authors to accept changes to use that API. > > <SNIP> > > > > What I've suggested on the security@ list was: > > > > Make a nice API which will wrap all this stuff up for good: > > - This API will log in a different file then wtmp/utmp/lastlog. > > - A program is free to use the API or not, though it is encouraged too > > (and basically the author of the program would be kinda stupid not to :) > > - API using programs can only "write" to the new API camouflaged system > > (be it a SQL database, a flat file whatever, the app won't see it). > > - The "old" utmp/wtmp/lastlog is wrapped in the API whenever something > > is queried... so... API using programs query for the last accounts used > > for logging in... > > The API then sees "hey we still use the old utmp/wtmp/lastlog stuff" > > and reads entries from there in addition to from it's own db/file > > whatever. > > > > The API should simply eat strings of undefined length or spit strings > > with predefined buffer lengths: > > > > Putlastlog(char *accountname, char *hostaddress, int af_type); > > Getlastlog(char *accountname, char *hostaddress, int *af_type, int > > acct_len, int host_len); > > > > Tada all problems solved.... And we could get more evil to have a small > > program in cron or something merge the "old" utmp/wtmp/lastlog stuff > > into the new API enabled form. > > And throw away the old entries. This could be done verywell as there are > > only a few programs 'relying' on reading from the files (eg w/who :). > > > > Another nice thing to do would be to make the API convinient to be used > > on other platforms, thus make a "old wrapper only" version which writes > > directly into utmp/wtmp/lastlog. > > This way programmers of the client apps are easier to be encouraged to > > use it, as they can simply use the wrapper on platforms which don't have > > the real API backend we want to have. > > > > Wrap the wrappers and make it all happy for yourself :) > > > > Greets, > > Jeroen > > > > > > ----------- > Peter C. Lai > University of Connecticut > Dept. of Residential Life | Programmer > Dept. of Molecular and Cell Biology | > Undergraduate Research Assistant/Honors Program > http://cowbert.2y.net/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107261850.f6QIoaa04255>