Bug#729746: MAXLOGNAME increased (17 -> 32)
On 25/11/2013 09:55, Petr Salinger wrote:
> together with revisisting
> getlogin/getlogin_r/setlogin
I reviewed those functions and AFAICT the consequences are not terribly
bad (see my previous mail). Are there other concerns?
> and dropping support for glibc
> compiled with "--enable-compatible-utmp" (the Debian one is compiled with
> --disable-compatible-utmp anyway).
Is this necessary? Removing BSD-compatible UTMP would prevent glibc from
ever being built on FreeBSD (e.g. if someday they want to add it to the
ports collection).
> The problem might be with <sys/proc.h>, but this header is
> problematic-all-time, due to expose of kernel internals.
Ugh. The resize of "struct session" looks very ugly. Specially with
s_mtx sharing space with the resized s_login...
This struct looks like it's meant to be shared with kernel, is that right?
Even if it wasn't, this could have lots of unwanted consequences... who
knows how many times this struct is being used to build other structs, etc.
What if we force userland to preserve the old length? Then the userland
syscall stubs could enforce proper checking in both directions.
> In fact, we are currently a little bit inconsistent, as we have
>
> <bits/utmp.h> #define UT_NAMESIZE 32
> <bits/utmpx.h> #define UT_NAMESIZE 32
> <sys/param.h> #define MAXLOGNAME 17
>
> But the ususal constraint is
>
> MAXLOGNAME should be == UT_NAMESIZE+1
Who relies on this constraint?
--
Robert Millan
Reply to: