Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2016 14:49:36 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        ed@nuxi.nl
Cc:        freebsd-arch@freebsd.org
Subject:   Re: is ut_user[] in struct utmpx NUL terminated?
Message-ID:  <201605252149.u4PLnaoG007496@gw.catspoiler.org>
In-Reply-To: <CABh_MKkY_puFRj8VX3eX2A3RJ8GeAQb%2BT8NhUEVOKohTmOWdhg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25 May, Ed Schouten wrote:
> Hi Don,
> 
> 2016-05-25 23:14 GMT+02:00 Don Lewis <truckman@freebsd.org>:
>> Going in the other direction, getutxent()
>> calls futx_to_utx(), which uses the FTOU_STRING() macro, which in turn
>> uses strncpy() to copy the data back out.
> 
> Keep in mind that strcpy() is called with a size that is at most one
> less than sizeof(ut->ut_user). The final byte in the array is never
> overwritten.

It looks like it is using sizeof() and not sizeof()-1 in both
directions:

Ah, it's using sizeof() going in, but I now see that there is a
carefully hidden -1 adjustment coming out:

#define FTOU_STRING(fu, ut, field) do { \
        strncpy((ut)->ut_ ## field, (fu)->fu_ ## field,         \
            MIN(sizeof (ut)->ut_ ## field - 1, sizeof (fu)->fu_ ## field)); \
} while (0)

We should probably document this in the man page.  The Linux man page
that I found online says that the string fields are NUL terminated only
if there is room.  The Mac OS X man page and Open Group documentation
are silent on this, which would lead one to think these fields are NUL
terminated.

Code also has be careful to not make the assumption that these fields
are NUL terminated if the struct utmpx has not been laundered through
pututxline() and getutx*(), though this should be rare.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201605252149.u4PLnaoG007496>