Increasing MAXLOGNAME from 17 to 33

[Baptiste Daroussin]

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

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?

Is there anything that have been missed there?

regards,
Bapt
-------------- 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/a9fcad13/attachment.sig>