Increasing MAXLOGNAME from 17 to 33

[Konstantin Belousov]

On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote:
> On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote:
> > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote:
> > > Hi,
> > > 
> > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 32-character
> > > long usernames, the PR: misc/161091 and misc/133926 already requested for it.
> > > 
> > > utmpx already allow 32 character long user names.
> > > 
> > > I plan to bump the __FreeBSD_version at the same time because of the ABI
> > > breakage.
> > > 
> > > This is simplify life of lots administrator, this value, is a common value for
> > > other operating systems.
> > > 
> > > Do anyone have objections about it?
> > 
> > Yes, I have. Do not break the ABI, it is plain prohibited.
> > You might consider increasing the constant only if providing ABI
> > compatibility shims.
> > 
> > In fact, the cursory look over the whole base system indicates that ABI
> > breakage might be not that big and could be mitigated with relatively
> > limited amount of the efforts.
> 
> Thanks cognet for the help on the following.
> 
> After auditing base, it seems like this patch is enough
> http://people.freebsd.org/~bapt/maxlogname-33.diff
Regarding the patch, the dereferencing of p->p_session should be done
under the proc lock to guarantee stability of p_pgrp, and under session
mutex to prevent s_login modifications. Altogether, this means that the
if() shall be moved down right before bcopy and locks unlocked on return.

> 
> The users of MAXLOGNAME in base are:
> bin/ps/ps.c
> kerberos5/lib/libgssapi_krb5/pname_to_uid.c
> lib/libc/posix1e/acl_to_text.c
> lib/libc/gen/getpwent.c
> lib/libc/gen/sysconf.c
> lib/libfetch/ftp.c
> lib/libc/gen/getlogin.c
> libexec/ftpd/ftpd.c
> libexec/atrun/atrun.c
> libexec/lukemftpd/nbsd2fbsd.h
> libexec/getty/main.c
> sys/sys/loginclass.h
> sys/sys/proc.h
> sys/kern/kern_prot.c
> sys/security/audit/audit_private.h
> sys/security/audit/audit_arg.c
> usr.bin/id/id.c
> usr.bin/at/at.c
> usr.bin/finger/sprint.c
> usr.bin/su/su.c
> usr.bin/find/ls.c
> usr.bin/login/login.c
> usr.bin/lastcomm/lastcomm.c
> usr.sbin/edquota/edquota.c
> usr.sbin/pwd_mkdb/pwd_mkdb.c
> usr.sbin/syslogd/syslogd.c
> usr.sbin/repquota/Repquota.c
> usr.sbin/sa/usrdb.c
> usr.sbin/pw/pwupd.c
> usr.sbin/pw/grupd.c
> usr.sbin/pw/pw_user.c
> usr.sbin/inetd/builtins.c
> 
> The way they use it is ok, I don't see any problem with them.
> We also checked usage of LOGIN_NAME_MAX _SC_LOGIN_NAME_MAX and nothing in base
> seems problematic at this point.
> 
> last getlogin(2) is always used in base, I saw no direct usage of _getlogin, and
> getlogin(2) correctly check the return value of _getlogin
> 
> Last this patch makes getlogin(2) return the ERANGE error as it should be
> according to its manpage?
I do not quite understand the sentences.

> 
> Is there anything that have been missed there?
Well, if the full audit of the base was performed and no issues are
indeed found, this should be fine.

I suggest to commit the fixed ERANGE patch separately. It definitely shall
be merged, not sure about MAXLOGNAME increase.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20121113/4fdb7f32/attachment.sig>