Date: Fri, 28 Jun 2002 11:34:54 -0400 From: Mike Barcroft <mike@FreeBSD.org> To: Robert Drehmel <robert@zoot.drehmel.com> Cc: current@FreeBSD.org, robert@FreeBSD.org Subject: Re: changing 'struct utmp' Message-ID: <20020628113454.B34516@espresso.q9media.com> In-Reply-To: <20020628110244.A34627@bsd.develop.ferrari.local>; from robert@zoot.drehmel.com on Fri, Jun 28, 2002 at 11:02:44AM %2B0200 References: <20020628110244.A34627@bsd.develop.ferrari.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Drehmel <robert@zoot.drehmel.com> writes: > While trying to fix the bug described in a problem report about > 'w -n', and finding out that it is somewhat broken*, I came to > the conclusion that our 'struct utmp' is too limiting. > > I would like to modernize it as follows: > > #define UT_USERSIZE 16 > #define UT_LINESIZE 8 > #define UT_HOSTSIZE 18 /* increase by two bytes */ I think it might be a wise idea to make UT_HOSTSIZE much larger. Currently, it isn't even large enough to hold an IPv6 address. > struct utmp { > char ut_user[UT_USERSIZE]; > char ut_line[UT_LINESIZE]; > char ut_host[UT_HOSTSIZE]; > uint8_t ut_type; /* new field */ > uint8_t ut_flags; /* new field */ > uint32_t ut_time; > struct sockaddr ut_saddr; /* new field */ > }; Have you considered starting with the standardized utmpx struct? It is defined as requiring at least these members: char ut_user[]; /* User login name. */ char ut_id[]; /* Unspecified initialization process identifier. */ char ut_line[]; /* Device name. */ pid_t ut_pid; /* Process ID. */ short ut_type; /* Type of entry. */ struct timeval ut_tv; /* Time entry was made. */ > leaving us with a 64 byte structure. I also have a patch for a > new function similiar to our login(3): utmp_login(), which takes > the user, line, host, type and sockaddr arguments, puts them into > a struct utmp and proceeds as in login(3). > > With the addition of ut_saddr we could store the plain raw network > address in daemons like sshd or telnetd and use the same field in > programs that use the 'struct utmp' to do the Right Thing. > > I know we have a pam_lastlog module that cares about utmp and > friends, but to my knowledge there is no simple way to transfer > the raw address data into the pam module; calling utmp_login() > in the daemons directly is straight forward. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020628113454.B34516>