[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 06/18] posix: Remove glob GET_LOGIN_NAME_MAX usage

From: Paul Eggert
Subject: Re: [PATCH 06/18] posix: Remove glob GET_LOGIN_NAME_MAX usage
Date: Sat, 2 Sep 2017 15:50:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 08/11/2017 07:50 AM, Adhemerval Zanella wrote:

There is no actual login to resize the buffer in case of the resizing
the buffer in case of ERANGE, so a static buffer using glibc default
LOGIN_NAME_MAX is suffice.

Although I had trouble parsing that, I think you're saying that because the current glob.c goes awry when sysconf (_SC_LOGIN_NAME_MAX) < 0, it's OK if we change glob.c to insist on a fixed-size limit of 255 bytes on user name length so that glob continues to mishandle (presumably mostly-theoretical) environments with longer user names. But that's not the GNU style, which is to avoid arbitrary limits. Instead, let's fix glob.c so that it doesn't need to know the user name length limit. Obviously glob should use heap allocation for anything large, which suggests that it should use a scratch buffer for the login name.

I looked into this, and it's easy enough to change glob.c to use the tail of the scratch buffer that it's already using for getpwnam_r (given your previously-proposed patches), and this simplifies glob's memory-allocation code. I installed the attached patch into Gnulib to do that. Please take a look at it for your next go-round with glibc. Thanks.

This is mostly-theoretical stuff, of course, as this code is exercised only when $HOME is unset or empty.

+             char user_name[LOGIN_NAME_MAX];

A nit: that array needs to be one byte bigger, for the trailing NULL. This point is irrelevant to the attached Gnulib patch, which doesn't use LOGIN_NAME_MAX.

Attachment: 0001-glob-fix-bugs-with-long-login-names.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]