Date: Tue, 13 Nov 2012 20:42:38 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: arch@freebsd.org Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113184238.GO73505@kib.kiev.ua> In-Reply-To: <20121113183412.GA75103@ithaqua.etoilebsd.net> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--4492t87HU5WhnhG2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > > >=20 > > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 3= 2-character > > > long usernames, the PR: misc/161091 and misc/133926 already requested= for it. > > >=20 > > > utmpx already allow 32 character long user names. > > >=20 > > > I plan to bump the __FreeBSD_version at the same time because of the = ABI > > > breakage. > > >=20 > > > This is simplify life of lots administrator, this value, is a common = value for > > > other operating systems. > > >=20 > > > Do anyone have objections about it? > >=20 > > Yes, I have. Do not break the ABI, it is plain prohibited. > > You might consider increasing the constant only if providing ABI > > compatibility shims. > >=20 > > 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. >=20 > Thanks cognet for the help on the following. >=20 > 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. >=20 > 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 >=20 > 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. >=20 > last getlogin(2) is always used in base, I saw no direct usage of _getlog= in, and > getlogin(2) correctly check the return value of _getlogin >=20 > 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. >=20 > 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. --4492t87HU5WhnhG2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCilJ4ACgkQC3+MBN1Mb4g8KQCgpKFBI1aDj66heZCccnJhAv2k 5psAn0UdAUPQ17WZlXm6GfrViYD5NcES =blfj -----END PGP SIGNATURE----- --4492t87HU5WhnhG2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121113184238.GO73505>