Bug#729746: MAXLOGNAME increased (17 -> 32)
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?
The getlogin_r is not thread safe, as it uses the same buffer as getlogin.
Thread A calls getlogin_r(), the __getlogin_cache is not NULL
and right before "len = strlen (__getlogin_cache)" is scheduled thread B.
which calls setlogin.
Result -> dereference of NULL pointer laster in thread A.
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).
I doubt we currently support it correctly, see changes
http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html
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.
We still could preserve "struct session" size.
Petr
Reply to: