Bug#729746: MAXLOGNAME increased (17 -> 32)

[Robert Millan <rmh@debian.org>]

On 16/11/2013 17:26, Robert Millan wrote:
> See:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=243023
> 
> Given that MAXLOGNAME is mirrored in <bits/param.h> and available to
> userland, this opens a few questions:

I've audited the getlogin / getlogin_r / setlogin family of functions.
My findings so far:

> - Does the new ABI create any security concerns? E.g. buffer overflows
> in userland.

There are no security concerns AFAICT. Both getlogin and getlogin_r use
the same syscall, which conveniently takes a user-defined length limit
as parameter instead of assuming MAXLOGNAME.

> - Should we update MAXLOGNAME in glibc?

As far as getlogin / getlogin_r / setlogin are concerned I think we
should. Programs will still fail if they receive a string longer than 17
bytes in getlogin / getlogin_r. [1]

> Would we need wrapper code in
> order to preserve compatibility with 9.x in case we did that?

Increasing MAXLOGNAME that is visible to userland creates the
expectation that setlogin() will accept 32 bytes.

Unfortunately I don't see anything that can be done about that in glibc
side. Perhaps we could patch our 9.x kernels to increase MAXLOGNAME
there as well?

But if we do that, we introduce problem [1] (see above) for older code
(e.g. Wheezy chroot).

> - Do we need to patch the kernel in order to preserve backward
> compatibility with old userland? (e.g. Wheezy chroot)

I can't see a way around it: either we break new code or we break old
code. Am I missing something?

We could also turn MAXLOGNAME into a sysconf() parameter, but that
changes syscall ABI and would have to be coordinated with upstream.

Adding Petr to CC, hoping for his wisdom :-)

-- 
Robert Millan