[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    Re: Increasing MAXLOGNAME from 17 to 33
From:       Konstantin Belousov <kostikbel () gmail ! com>
Date:       2012-11-14 5:45:23
Message-ID: 20121114054523.GU73505 () kib ! kiev ! ua
[Download RAW message or body]


On Tue, Nov 13, 2012 at 04:04:33PM -0700, Warner Losh wrote:
> 
> On Nov 13, 2012, at 3:59 PM, Baptiste Daroussin wrote:
> 
> > On Tue, Nov 13, 2012 at 08:45:12PM +0200, Konstantin Belousov wrote:
> >> 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,
> >>>>>> 
> >>>>>> 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.
> >>> 
> >> Sorry, sent the reply too early.
> >> 
> >> The alternative is to check for the length of the local 'login' variable
> >> after unlocks, right before copyout.
> >> 
> > like this?
> > http://people.freebsd.org/~bapt/report-erange-if-login-is-larger-then-MAXLOGNAME.diff
> 
> Isn't that check too late?
> 

No, it is not, The uap->namelen is clamped before the block shown in the
patch. I think that the patch is fine and should be merged into stable
branches as well.

While there, you could add a space between 'return' and '(' in the last
line of the sys_getlogin(), in separate commit.

Thanks.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]