Date: Tue, 13 Nov 2012 20:45:12 +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: <20121113184512.GP73505@kib.kiev.ua> In-Reply-To: <20121113184238.GO73505@kib.kiev.ua> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> <20121113184238.GO73505@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--XfTwdTn5e7P36tOV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 08:42:38PM +0200, Konstantin Belousov wrote: > 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= 32-character > > > > long usernames, the PR: misc/161091 and misc/133926 already request= ed 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 th= e ABI > > > > breakage. > > > >=20 > > > > This is simplify life of lots administrator, this value, is a commo= n 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 A= BI > > > 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 Sorry, sent the reply too early. The alternative is to check for the length of the local 'login' variable after unlocks, right before copyout. > >=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 _getl= ogin, 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 > >=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. >=20 > I suggest to commit the fixed ERANGE patch separately. It definitely shall > be merged, not sure about MAXLOGNAME increase. --XfTwdTn5e7P36tOV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCilTcACgkQC3+MBN1Mb4iOxACfd7xUkDg++oVpMyuHm9e16onI 2WgAoLzXBlbXJnH9OZctTWjQ9i9/SmNK =7XyR -----END PGP SIGNATURE----- --XfTwdTn5e7P36tOV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121113184512.GP73505>