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>