Date: Mon, 6 Jan 1997 19:02:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pst@shockwave.com (Paul Traina) Cc: phk@critter.dk.tfs.com, jkh@freebsd.org, current@freebsd.org Subject: Re: utmp changes Message-ID: <199701070202.TAA13434@phaeton.artisoft.com> In-Reply-To: <199701031916.LAA15717@precipice.shockwave.com> from "Paul Traina" at Jan 3, 97 11:16:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
> No what I wanted was a space for the key-name for ssh and a flag for the > fact that the session is encrypted. > > OK, then it was someone else who was talking about larger hostname sizes > and IP addresses. I'm more concerned about either making the space now, > or at least creating a "RESERVED" area (we should do that anyway) in utmp > and wtmp. > > To start the ball rolling, let me just suggest the following. I know it's > not pretty, and I'm not so sure that the remote ssh key belongs in utmp, > but this is what I conceive as changing. The big thing is I'd like to fix > the size of the utmp structure once and for all, and define the reserved > area as must-be-zero so we don't get in the mess we just got in ever again. :-( I would like to suggest a record size field for the next record. Alternatively, I'd like to suggest a version field, and a version tag on the structure names with a version flagged section for the unversioned name definition for compatability. Either one of these would let the utmp/wtmp record format change within a single file, and would allow future changes to be painless; the version tagged structure names would allow for simple conversion programs. A version would be more flexible, but lose backward compatability; a size would only allow growth, but could maintain general compatability of outdated tools running against a newer set of data. 8-(. I believe the ssh key is actually session information; session information does not belong in utmp/wtmp; especially, an ssh key does not belong in utmp, and wtmp is still a bit problematic, though less so than utmp. We need to abstract the ability to do session management; I should be able to attach any type of credential information to my current session credential, and all credential references for my user should refrence the addended credential (ie: refrence count it instead of duping it around for new logins by the same user, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701070202.TAA13434>