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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
