Re: Badly formatted 'ls -l'

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> Please let us know if this is of more than theoretical interest.
> If it's the one I'm thinking of, there was so much slack in the other
> terms contributing to that buffer's length that one would be very
> hard-pressed to contrive circumstances to provoke an actual overrun.

The only circumstances that I can see is when the attacker has some
control over user names, and can request a very long user name (or
group), e.g. for a nonce account.  This isn't likely in wuftpd-like
scenarios.  I could probably construct a scenario where it is
possible, but it's not one I've ever run into myself.

> I replaced these lines
>   dired_pos += width;
>   dired_pos++;
> with this one
>   dired_pos += width + 1;

Actually, it'd be better to uniformly use

  dired_pos += width;
  dired_pos++;

since it works in some cases when the "width + 1" form does not work.
For example, in the common case where int is 32-bits and size_t is
64-bits, "width + 1" will overflow when width is INT_MAX, but the
two-line form will work correctly.  (Admittedly it's not very likely
for strlen (username) to be INT_MAX, but I'm sure you can arrange it
with the Hurd.  :-)