From darrenm@sac.sfbay.sun.com Thu May 20 09:02:03 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KG23JL023126 for ; Thu, 20 May 2010 09:02:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KG22ie035282; Thu, 20 May 2010 10:02:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00H0T77ETY00@nwk-avmta-2.sfbay.sun.com>; Thu, 20 May 2010 09:02:02 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00EAE77DBH80@nwk-avmta-2.sfbay.sun.com>; Thu, 20 May 2010 09:02:01 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KG20L0002076; Thu, 20 May 2010 09:02:00 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KG1wfV023105; Thu, 20 May 2010 09:01:58 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4KG1wsY023101; Thu, 20 May 2010 09:01:58 -0700 (PDT) Date: Thu, 20 May 2010 09:01:58 -0700 (PDT) From: Darren J Moffat Subject: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] To: PSARC-ext@sun.com Message-id: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3771 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Username legnth 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 20 May, 2010 4. Technical Description Solaris currently documents a maximum username length of 8 characters in passwd(4). Other Operating Systems don't have such a small limit. In fact Solaris mostly works and has for quite some time with usernames upto 32 characters. The 8 character limit is manifest in three places 1) the LOGNAME_MAX constant in (8) 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9) This symbol is deprecated for XPG6 / SUSv3 onwards. 3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9) The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX is the minumum acceptable value. That implies that they need not be the same. This case changes so that we have: 1) the LOGNAME_MAX constant in (32) 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33) This symbol is deprecated for XPG6 / SUSv3 onwards. 3) getconf _POSIX_LOGIN_NAME_MAX (9) 4) getconf LOGIN_NAME_MAX (33) Going beyond 32 characters for the username is more complex since utmpx(4) is defined to have the ut_user/ut_name field as 32 characters, changing this would very likely break consumers of getutexent(3C) even if they were all able to be recompiled. This case proposes to change the documented limit in passwd(4) from 8 to 32 and declare that anything not implementing that is a bug. This case does not require that any part of the system enforce 32 as an upper limit (though some may), only that it is a bug that providing it doesn't break standards if they enforce the legacy behaviour of 8 and that they accept and use 32 character long usernames. "Work" does not require that all output fields that "line up" with 8 character long usernames still "line up" when using 32 character long usernames. Ideally code should use sysconf to lookup LOGIN_NAME_MAX but there is also a lot of exsting that derives the size using something like this: (sizeof (((struct utmpx *)0)->ut_name)) The method for fixing utilities that are currently restricted to 8 character usernames is outside the scope of the ARC case and is really an issue for the codereviewers and CRT advocates. Though it is highly recommended that "32" not be hardcoded into a local constant but instead either LOGNAME_MAX from be used or if possible sysconf(3C), the method of using the ut_name field is acceptable particularly if it means minimal code change. When this case integrates the following bugs will be fixed 4169241 LOGNAME_MAX should be greater than 8. 4033673 passwd cannot be changed if login id is longer than 8 characters 4109819 user names longer than 8 characters needed 4431427 *useradd* useradd(1M) should not complain about a username longer than 8 char 4435330 *logname* logname prints out only part of long login name 4909548 system tools allow to create usernames > 8 chars. 4927530 *w* w(1) truncates usernames to 8 chars 6551524 su truncates LOGNAME for long usernames. 6627292 *cron* confused about username lengths 6819489 *su* sulog source username truncated to 8 chars but destination name not 6866548 last command does not support usernames longer than 8 characters 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@oracle.com Thu May 20 09:08:55 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KG8sdm023241 for ; Thu, 20 May 2010 09:08:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KG8sHi019229 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 09:08:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00C117IUZR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:08:54 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q0005E7ITUXD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:08:53 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KG8q2I000940 for ; Thu, 20 May 2010 16:08:53 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KEsM8b002682 for ; Thu, 20 May 2010 16:08:51 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 285065201274371651; Thu, 20 May 2010 09:07:31 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 09:07:31 -0700 Date: Thu, 20 May 2010 17:07:29 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> To: PSARC-ext@sun.com Message-id: <4BF55E41.7050806@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BF55E94.00EE:SCFMA4539814,ss=1,fgs=0 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 260 The correct title is "Username length" and the time out is 5/27/2010 not 2/27/2010. The release binding is minor the taxonomy of the interfaces is unchanged from their existing taxonomy which would be Committed/Standard in most cases. -- Darren J Moffat From garrett.damore@oracle.com Thu May 20 09:11:17 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KGBGcP023271 for ; Thu, 20 May 2010 09:11:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KGBB1k041387 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 10:11:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00J0T7MQ9R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 09:11:14 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q005BS7MPBLF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 09:11:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KGB3SF017029; Thu, 20 May 2010 16:11:03 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KGAxca027564; Thu, 20 May 2010 16:11:00 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 285072681274371765; Thu, 20 May 2010 09:09:25 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 09:09:25 -0700 Date: Thu, 20 May 2010 09:09:21 -0700 From: "Garrett D'Amore" Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4BF55EB1.7010006@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BF55F16.019B:SCFMA4539814,ss=1,fgs=0 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 4081 +1, thanks for the great background research on this. (Even with the typo in the title.) - Garrett On 05/20/10 09:01 AM, Darren J Moffat wrote: > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > Username legnth > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 20 May, 2010 > 4. Technical Description > > Solaris currently documents a maximum username length of 8 characters > in passwd(4). > > Other Operating Systems don't have such a small limit. In fact Solaris > mostly works and has for quite some time with usernames upto 32 > characters. > > The 8 character limit is manifest in three places > 1) the LOGNAME_MAX constant in (8) > 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9) > This symbol is deprecated for XPG6 / SUSv3 onwards. > 3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9) > > The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns > the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX > is the minumum acceptable value. That implies that they need not be > the same. > > This case changes so that we have: > 1) the LOGNAME_MAX constant in (32) > 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33) > This symbol is deprecated for XPG6 / SUSv3 onwards. > 3) getconf _POSIX_LOGIN_NAME_MAX (9) > 4) getconf LOGIN_NAME_MAX (33) > > Going beyond 32 characters for the username is more complex since > utmpx(4) is defined to have the ut_user/ut_name field as 32 characters, > changing this would very likely break consumers of getutexent(3C) even > if they were all able to be recompiled. > > This case proposes to change the documented limit in passwd(4) from 8 > to 32 and declare that anything not implementing that is a bug. This > case does not require that any part of the system enforce 32 as an > upper limit (though some may), only that it is a bug that providing > it doesn't break standards if they enforce the legacy behaviour of 8 > and that they accept and use 32 character long usernames. "Work" does > not require that all output fields that "line up" with 8 character long > usernames still "line up" when using 32 character long usernames. > > Ideally code should use sysconf to lookup LOGIN_NAME_MAX but there is > also a lot of exsting that derives the size using something like this: > (sizeof (((struct utmpx *)0)->ut_name)) > > > The method for fixing utilities that are currently restricted to 8 > character usernames is outside the scope of the ARC case and is really > an issue for the codereviewers and CRT advocates. Though it is highly > recommended that "32" not be hardcoded into a local constant but > instead either LOGNAME_MAX from be used or if possible > sysconf(3C), the method of using the ut_name field is acceptable > particularly if it means minimal code change. > > When this case integrates the following bugs will be fixed > > 4169241 LOGNAME_MAX should be greater than 8. > 4033673 passwd cannot be changed if login id is longer than 8 characters > 4109819 user names longer than 8 characters needed > 4431427 *useradd* useradd(1M) should not complain about a username longer than 8 char > 4435330 *logname* logname prints out only part of long login name > 4909548 system tools allow to create usernames> 8 chars. > 4927530 *w* w(1) truncates usernames to 8 chars > 6551524 su truncates LOGNAME for long usernames. > 6627292 *cron* confused about username lengths > 6819489 *su* sulog source username truncated to 8 chars but destination name not > 6866548 last command does not support usernames longer than 8 characters > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From gww@sac.sfbay.sun.com Thu May 20 09:48:52 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KGmqAQ023747 for ; Thu, 20 May 2010 09:48:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KGmqVT004006 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 09:48:52 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00G039DFM000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:48:51 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00EKQ9DFD530@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:48:51 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KGmoEY024139; Thu, 20 May 2010 09:48:50 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KGmot6023745; Thu, 20 May 2010 09:48:50 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4KGmojk023744; Thu, 20 May 2010 09:48:50 -0700 (PDT) Date: Thu, 20 May 2010 09:48:50 -0700 (PDT) From: Gary Winiger Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] To: PSARC-ext@sun.com, darrenm@sac.sfbay.sun.com Message-id: <201005201648.o4KGmojk023744@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 256 > Solaris currently documents a maximum username length of 8 characters > in passwd(4). > > Other Operating Systems don't have such a small limit. In fact Solaris > mostly works and has for quite some time with usernames upto 32 > characters. +1 Gary.. From gisburn@gmail.com Thu May 20 10:50:39 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KHodbG024711 for ; Thu, 20 May 2010 10:50:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KHodrP029565 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 12:50:39 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00M03C8FXI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:50:39 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00L4UC8EYZ10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 10:50:38 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KHfCMY023744 for ; Thu, 20 May 2010 17:50:37 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-2279713 for PSARC-ext@sun.com; Thu, 20 May 2010 17:50:37 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-220722298 for PSARC-ext@sun.com; Thu, 20 May 2010 17:50:37 +0000 (Z) Received: from mail-gy0-f177.google.com ([209.85.160.177] [209.85.160.177]) by relay1i.sun.com with ESMTP id BT-MMP-14522712 for PSARC-ext@sun.com; Thu, 20 May 2010 17:50:37 +0000 (Z) Received: by gyb11 with SMTP id 11so42987gyb.8 for ; Thu, 20 May 2010 10:50:28 -0700 (PDT) Received: by 10.231.146.140 with SMTP id h12mr358145ibv.58.1274377827372; Thu, 20 May 2010 10:50:27 -0700 (PDT) Received: by 10.231.17.11 with HTTP; Thu, 20 May 2010 10:50:27 -0700 (PDT) Date: Thu, 20 May 2010 19:50:27 +0200 From: Roland Mainz Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> Sender: gisburn@gmail.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3gedyZj6nYQEp2dhPz+sHNM2F8QU31ihafJyqL4D2kg=; b=mUne4e+hrSmRfkcnEwc2GqcwKH1BwdGHgPd+l5jJ9ff4iZusyjTccyNmVk64XCMAKO yHR4p2M2o8EqSIfeFG1Mk0fizF3cgQ+M3B8cRpOaSGO/7REdrfKeNzoPTg/JS56TVI48 ltDDtOxZg4sT6a4tcRiPTG3r5o/pO+2HqYURc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DC9uadnRH0+EHx1EjTAWwCXJ9s8xgYHcdm7yIjC/HtBEDQEU+yLeoddCVtdBNoPXkd A0xu/nkojCfvrrz5zmCqU7rLqDCKve0AUIKKHdfQUFJEl8skTA3YQT8BMI4G37tdqE5B P1S8LCaYeB06d/VhunYXHCt+wjA2cgVSNUmQg= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 4nCIZi2UdflrSRK5TTz5P5WI1ZE X-Antispam: No, score=0.0/5.0, scanned in 0.095sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o4KHodbG024711 Status: RO Content-Length: 3758 On Thu, May 20, 2010 at 6:01 PM, Darren J Moffat wrote: > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction >    1.1. Project/Component Working Name: >         Username legnth >    1.2. Name of Document Author/Supplier: >         Author:  Darren Moffat >    1.3  Date of This Document: >        20 May, 2010 > 4. Technical Description > > Solaris currently documents a maximum username length of 8 characters > in passwd(4). Erm... AFAIK this should be _bytes_, not characters. Characters would be multibyte characters in this context with the small twist that tools like Solaris's tools like "useradd" always restricted this to the ASCII character set while many sites allow (by using their own set of tools) non-ASCII usernames (e.g. German umlauts are commonly used on German university sites and some japanese customers have been using Japanese characters for some time) and other operating systems even allow a larger set of multibyte characters to be used. IMO this case should either allow the use of multibyte characters or expcitly refer to bytes/ASCII characters (see below). > Other Operating Systems don't have such a small limit.  In fact Solaris > mostly works and has for quite some time with usernames upto 32 > characters. s/character/byte/. > The 8 character limit is manifest in three places >        1) the LOGNAME_MAX constant in  (8) >        2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9) >           This symbol is deprecated for XPG6 / SUSv3 onwards. >        3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9) > > The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns > the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX > is the minumum acceptable value.   That implies that they need not be > the same. > > This case changes so that we have: >        1) the LOGNAME_MAX constant in  (32) >        2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33) >           This symbol is deprecated for XPG6 / SUSv3 onwards. >        3) getconf _POSIX_LOGIN_NAME_MAX (9) >        4) getconf LOGIN_NAME_MAX (33) > > Going beyond 32 characters for the username is more complex since > utmpx(4) is defined to have the ut_user/ut_name field as 32 characters, > changing this would very likely break consumers of getutexent(3C) even > if they were all able to be recompiled. > > This case proposes to change the documented limit in passwd(4) from 8 > to 32 and declare that anything not implementing that is a bug.   This > case does not require that any part of the system enforce 32 as an > upper limit (though some may), only that it is a bug that providing > it doesn't break standards if they enforce the legacy behaviour of 8 > and that they accept and use  32 character long usernames.  "Work" does > not require that all output fields that "line up" with 8 character long > usernames still "line up" when using 32 character long usernames. I would give this case (if I could) a +1 with two minor changes: 1. "useradd" should clamp the string to 32bytes but _validate_ that the input username doesn't get any multibyte characters cut-off in the middle. 2. "useradd" should print a warning if non-ASCII characters (e.g. umlauts in ISO 8859-1/15) or multibyte characters are used unless a specific option is provided (e.g. -W) This is easy to do... if you don't have time I can volunteer to do this modification. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From dcragun@sonic.net Thu May 20 12:19:04 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KJJ47L027040 for ; Thu, 20 May 2010 12:19:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KJJ3Kv011166 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:19:03 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q0060HGBRHF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:19:03 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003MBGBQ3P20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:19:02 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KJJ1Gk012243 for ; Thu, 20 May 2010 19:19:01 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-3754091 for PSARC-ext@sun.com; Thu, 20 May 2010 19:19:01 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-220898858 for PSARC-ext@sun.com; Thu, 20 May 2010 19:19:00 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-8376725 for PSARC-ext@sun.com; Thu, 20 May 2010 19:19:00 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4KJIxjN017514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 May 2010 12:18:59 -0700 Date: Thu, 20 May 2010 12:18:58 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: To: PSARC-ext@sun.com Message-id: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.339sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: Status: RO Content-Length: 1058 The reason that LOGNAME_MAX was stuck at 8 in for so long is that the System V ABIs and the SCDs require that value. Solaris 10 has been breaking ABI requirements around the edges for a few years. Since this is case is departing from more ABI requirements, should it have a major release binding? Or, should an opinion be written for this case acknowledging that the ARC knows that this case violates the ABIs and that the decision to do so is intentional (without setting precedent to otherwise ignore the ABI)? Once upon a time, there was a gang of four working on a definition of what would be the limits of the changes going into "Solaris next", whether it would be classified as a major or minor release, and what would constitute the basis for determining whether or not an implementation of OpenSolaris would be able to use the Solaris trademark. Was a report ever produced by the gang? (I know that at least half of the gang no longer works for Sun/Oracle.) Is there any current plan to define any type of new Solaris ABI? - Don From Nicolas.Williams@oracle.com Thu May 20 13:01:20 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KK1KPR027894 for ; Thu, 20 May 2010 13:01:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KK1K4w040355 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:01:20 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00A03IA86D00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:01:20 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003U8IA73K50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:01:19 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KK1JUb014941 for ; Thu, 20 May 2010 20:01:19 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KEsMTs010237; Thu, 20 May 2010 20:01:14 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 285764161274385666; Thu, 20 May 2010 13:01:06 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 13:01:06 -0700 Date: Thu, 20 May 2010 15:01:01 -0500 From: Nicolas Williams Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> To: Don Cragun Cc: PSARC-ext@sun.com Message-id: <20100520200101.GR9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BF5950B.0028:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 2097 On Thu, May 20, 2010 at 12:18:58PM -0700, Don Cragun wrote: > The reason that LOGNAME_MAX was stuck at 8 in for so long > is that the System V ABIs and the SCDs require that value. > > Solaris 10 has been breaking ABI requirements around the edges for a > few years. Since this is case is departing from more ABI > requirements, should it have a major release binding? Or, should an > opinion be written for this case acknowledging that the ARC knows > that this case violates the ABIs and that the decision to do so is > intentional (without setting precedent to otherwise ignore the ABI)? > > Once upon a time, there was a gang of four working on a > definition of what would be the limits of the changes going into > "Solaris next", whether it would be classified as a major or minor > release, and what would constitute the basis for determining whether IMO the 8 byte limit on usernames is so onerous and obnoxious that regardless of anyone might classify this change's release binding (Major or Minor), the change has got to be made. Even 32 bytes is too short, but the utmpx ABI breakage issues seem more severe (or at least complex) than all the other ABI issues that might arise from going from 8 to 32 bytes. The _POSIX_LOGIN_NAME_MAX and LOGIN_NAME_MAX getconfs could be made configurable, but given that there's not much that can be done about determining LOGNAME_MAX and L_cuserid at run-time, the last two can and must only be changed to allow for 32-byte usernames. In any case, customers that require strict SysV ABI compliance (e.g., customers that have apps that use LOGNAME_MAX and/or L_cuserid and who cannot or will not re-build those apps) can always stick to creating usernames with 8 or fewer bytes. Yes, there could be a configuration setting so that useradd knows to enforce 8 byte usernames in that case, but such a thing seems rather useless to me, and the default had better be 32 bytes anyways. > or not an implementation of OpenSolaris would be able to use the > Solaris trademark. [...] (Did you mean the UNIX trademark?) Perhaps Nico -- From garrett.damore@oracle.com Thu May 20 13:31:04 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKV4Jo028233 for ; Thu, 20 May 2010 13:31:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KKV2Ze055365 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:31:03 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00C01JNRRF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:31:03 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00376JNM3P70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:31:03 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KKUwWJ024969 for ; Thu, 20 May 2010 20:30:58 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4K1kaIZ004326; Thu, 20 May 2010 20:30:53 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 255318831274387375; Thu, 20 May 2010 13:29:35 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 13:29:34 -0700 Date: Thu, 20 May 2010 13:29:28 -0700 From: "Garrett D'Amore" Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <20100520200101.GR9605@oracle.com> To: Nicolas Williams Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4BF59BA8.3080501@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BF59BFD.0219:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 3064 I concur fully with Nico on this one. Further, customers requiring strict compliance can run an S10 zone. I think we're no longer in 1980's style SVID anymore -- already there have been other issues where we have deviated -- from certain ZFS semantics to packaging, so that we're no longer tracking SysV anymore. While I don't speak for Oracle management, one might suppose that strict compliance to AT&T System V is probably no longer terribly relevant -- at least not to the vast majority of our users and customers. What, however, is relevant, is that we don't break the applications that users already have in place. I think the risk -- and mitigation as suggested by Nico -- in this case is reasonable -- particularly given the benefits of a longer username, and so my +1 on the case stands. -- Garrett On 05/20/10 01:01 PM, Nicolas Williams wrote: > On Thu, May 20, 2010 at 12:18:58PM -0700, Don Cragun wrote: > >> The reason that LOGNAME_MAX was stuck at 8 in for so long >> is that the System V ABIs and the SCDs require that value. >> >> Solaris 10 has been breaking ABI requirements around the edges for a >> few years. Since this is case is departing from more ABI >> requirements, should it have a major release binding? Or, should an >> opinion be written for this case acknowledging that the ARC knows >> that this case violates the ABIs and that the decision to do so is >> intentional (without setting precedent to otherwise ignore the ABI)? >> >> Once upon a time, there was a gang of four working on a >> definition of what would be the limits of the changes going into >> "Solaris next", whether it would be classified as a major or minor >> release, and what would constitute the basis for determining whether >> > IMO the 8 byte limit on usernames is so onerous and obnoxious that > regardless of anyone might classify this change's release binding (Major > or Minor), the change has got to be made. Even 32 bytes is too short, > but the utmpx ABI breakage issues seem more severe (or at least complex) > than all the other ABI issues that might arise from going from 8 to 32 > bytes. > > The _POSIX_LOGIN_NAME_MAX and LOGIN_NAME_MAX getconfs could be made > configurable, but given that there's not much that can be done about > determining LOGNAME_MAX and L_cuserid at run-time, the last two can and > must only be changed to allow for 32-byte usernames. > > In any case, customers that require strict SysV ABI compliance (e.g., > customers that have apps that use LOGNAME_MAX and/or L_cuserid and who > cannot or will not re-build those apps) can always stick to creating > usernames with 8 or fewer bytes. Yes, there could be a configuration > setting so that useradd knows to enforce 8 byte usernames in that case, > but such a thing seems rather useless to me, and the default had better > be 32 bytes anyways. > > >> or not an implementation of OpenSolaris would be able to use the >> Solaris trademark. [...] >> > (Did you mean the UNIX trademark?) > > Perhaps > > Nico > From dcragun@sonic.net Thu May 20 13:37:52 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKbqsT028269 for ; Thu, 20 May 2010 13:37:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KKbqMt058620 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:37:52 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00D01JZ4BD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:37:52 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003A4JZ33R70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:37:51 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KKSgZe016038 for ; Thu, 20 May 2010 20:37:51 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-918792 for PSARC-ext@sun.com; Thu, 20 May 2010 20:37:49 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-729569 for PSARC-ext@sun.com; Thu, 20 May 2010 20:37:48 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay1i.sun.com with ESMTP id BT-MMP-14946303 for PSARC-ext@sun.com; Thu, 20 May 2010 20:37:48 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4KKbl0a024531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 May 2010 13:37:47 -0700 Date: Thu, 20 May 2010 13:37:47 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <20100520200101.GR9605@oracle.com> To: PSARC-ext@sun.com Message-id: <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.090sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> Status: RO Content-Length: 3387 On May 20, 2010, at 1:01 PM, Nicolas Williams wrote: > On Thu, May 20, 2010 at 12:18:58PM -0700, Don Cragun wrote: >> The reason that LOGNAME_MAX was stuck at 8 in for so long >> is that the System V ABIs and the SCDs require that value. >> >> Solaris 10 has been breaking ABI requirements around the edges for a >> few years. Since this is case is departing from more ABI >> requirements, should it have a major release binding? Or, should an >> opinion be written for this case acknowledging that the ARC knows >> that this case violates the ABIs and that the decision to do so is >> intentional (without setting precedent to otherwise ignore the ABI)? >> >> Once upon a time, there was a gang of four working on a >> definition of what would be the limits of the changes going into >> "Solaris next", whether it would be classified as a major or minor >> release, and what would constitute the basis for determining whether > > IMO the 8 byte limit on usernames is so onerous and obnoxious that > regardless of anyone might classify this change's release binding (Major > or Minor), the change has got to be made. Even 32 bytes is too short, > but the utmpx ABI breakage issues seem more severe (or at least complex) > than all the other ABI issues that might arise from going from 8 to 32 > bytes. I'm not disagreeing with the move to 32 bytes. I just believe that the ARC needs to make it clear that doing so is a conscious decision to break the ABIs and that it does not set a precedent for other ABI breakage. If I remember correctly, an opinion needs to be written to do that even if this is just a fast track case. > > The _POSIX_LOGIN_NAME_MAX and LOGIN_NAME_MAX getconfs could be made > configurable, but given that there's not much that can be done about > determining LOGNAME_MAX and L_cuserid at run-time, the last two can and > must only be changed to allow for 32-byte usernames. > > In any case, customers that require strict SysV ABI compliance (e.g., > customers that have apps that use LOGNAME_MAX and/or L_cuserid and who > cannot or will not re-build those apps) can always stick to creating > usernames with 8 or fewer bytes. Yes, there could be a configuration > setting so that useradd knows to enforce 8 byte usernames in that case, > but such a thing seems rather useless to me, and the default had better > be 32 bytes anyways. > >> or not an implementation of OpenSolaris would be able to use the >> Solaris trademark. [...] > > (Did you mean the UNIX trademark?) No. The Open Group controls the definition of what implementations must do in order to use the UNIX trademark. To enforce its control over the trademark, The Open Group publishes the Single UNIX Specifications, creates test suites to be used as an indicator of conformance to the SUS, requires documentation for all behavior described by SUS as "implementation-defined", requires timely fixes for non-conforming behavior detected by TOG or by users, charges fees for administration of the branding program, etc. Once upon a time, Sun was planning to do the same thing with the Solaris trademark and/or the OpenSolaris trademark. This part of this discussion is probably off-topic for this case, but I would like the ARC to address this issue at some point in a future OpenSolaris ARC meeting as a topic on the agenda. - Don > > Perhaps > > Nico > -- > From alan.coopersmith@oracle.com Thu May 20 13:42:31 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKgVSk028301 for ; Thu, 20 May 2010 13:42:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KKgU4k016531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 13:42:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00D0BK6VQ600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:42:31 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003MIK6U3P70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:42:30 -0600 (MDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KKgUJG021325; Thu, 20 May 2010 13:42:30 -0700 (PDT) Date: Thu, 20 May 2010 13:42:30 -0700 From: Alan Coopersmith Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <20100520200101.GR9605@oracle.com> To: Nicolas Williams Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4BF59EB6.9060609@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 814 Nicolas Williams wrote: > In any case, customers that require strict SysV ABI compliance (e.g., > customers that have apps that use LOGNAME_MAX and/or L_cuserid and who > cannot or will not re-build those apps) can always stick to creating > usernames with 8 or fewer bytes. If that is to be a supported scenario, then all system provided account names should remain within the 8 character limit. Obviously they already have to for any case requesting a patch binding for possible backport to an older release, but ARC should decide whether cases that only deliver after this change should be able to add system accounts with longer usernames ("postgresql" instead of "postgres" for instance). -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From Nicolas.Williams@oracle.com Thu May 20 13:47:58 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKlvm7028315 for ; Thu, 20 May 2010 13:47:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KKls0p024040 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 15:47:57 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00J03KFXBZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:47:57 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00BPNKFWNL20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:47:56 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KKlubh000796 for ; Thu, 20 May 2010 20:47:56 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KKlmu2005839; Thu, 20 May 2010 20:47:49 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 255360621274388359; Thu, 20 May 2010 13:45:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 13:45:59 -0700 Date: Thu, 20 May 2010 15:45:54 -0500 From: Nicolas Williams Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF59EB6.9060609@oracle.com> To: Alan Coopersmith Cc: Don Cragun , PSARC-ext@sun.com Message-id: <20100520204554.GW9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BF59FF6.0021:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <4BF59EB6.9060609@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1095 On Thu, May 20, 2010 at 01:42:30PM -0700, Alan Coopersmith wrote: > Nicolas Williams wrote: > > In any case, customers that require strict SysV ABI compliance (e.g., > > customers that have apps that use LOGNAME_MAX and/or L_cuserid and who > > cannot or will not re-build those apps) can always stick to creating > > usernames with 8 or fewer bytes. > > If that is to be a supported scenario, then all system provided account > names should remain within the 8 character limit. Obviously they already > have to for any case requesting a patch binding for possible backport to > an older release, but ARC should decide whether cases that only deliver > after this change should be able to add system accounts with longer usernames > ("postgresql" instead of "postgres" for instance). Not necessarily. We could have pkgs that will only work in a non-standards-compliant installation. Certainly in /contrib :) But, yes, I agree. This could be enforced by IPS or checked for by the recently proposed IPS lint checker. I suspect Darren will claim all of that is "not this case". Nico -- From carlsonj@workingcode.com Thu May 20 13:50:42 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKog4k028330 for ; Thu, 20 May 2010 13:50:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KKof7f025385 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 15:50:41 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00K05KKH0V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:50:41 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00BBYKKHNP20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 13:50:41 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KKoe4s004125 for ; Thu, 20 May 2010 20:50:41 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-89255 for PSARC-ext@sun.com; Thu, 20 May 2010 20:50:40 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-165348915 for PSARC-ext@sun.com; Thu, 20 May 2010 20:50:39 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-11462579 for PSARC-ext@sun.com; Thu, 20 May 2010 20:50:39 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4KKoUAQ004064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 16:50:31 -0400 (EDT) Date: Thu, 20 May 2010 16:50:30 -0400 From: James Carlson Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF59EB6.9060609@oracle.com> To: Alan Coopersmith Cc: Nicolas Williams , PSARC-ext@sun.com, Don Cragun Message-id: <4BF5A096.5080600@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-z.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.226sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <4BF59EB6.9060609@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1162 Alan Coopersmith wrote: > Nicolas Williams wrote: >> In any case, customers that require strict SysV ABI compliance (e.g., >> customers that have apps that use LOGNAME_MAX and/or L_cuserid and who >> cannot or will not re-build those apps) can always stick to creating >> usernames with 8 or fewer bytes. > > If that is to be a supported scenario, then all system provided account > names should remain within the 8 character limit. Obviously they already > have to for any case requesting a patch binding for possible backport to > an older release, but ARC should decide whether cases that only deliver > after this change should be able to add system accounts with longer usernames > ("postgresql" instead of "postgres" for instance). If there are any files shared by NFSv4 with owner or group set to system accounts, then I think that issue may become a little more serious. If I recall correctly, NFSv4 does mapping by name rather than by ID number. Just for the sake of sanity, I'd like to see a rule limiting system-supplied names to 8 characters, at least for a while. -- James Carlson 42.703N 71.076W From dcragun@sonic.net Thu May 20 14:05:14 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KL5ENA028837 for ; Thu, 20 May 2010 14:05:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KL5DMe016309 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:05:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q0000XL8PN000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:05:13 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00BANL8ONH40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:05:12 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KKw5dn002616 for ; Thu, 20 May 2010 21:05:12 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-1152107 for PSARC-ext@sun.com; Thu, 20 May 2010 21:04:56 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-163893539 for PSARC-ext@sun.com; Thu, 20 May 2010 21:04:56 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay4i.sun.com with ESMTP id BT-MMP-3868567 for PSARC-ext@sun.com; Thu, 20 May 2010 21:04:56 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4KL4r4D008685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 May 2010 14:04:53 -0700 Date: Thu, 20 May 2010 14:04:53 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF59BA8.3080501@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.176sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <4BF59BA8.3080501@oracle.com> Status: RO Content-Length: 1394 On May 20, 2010, at 1:29 PM, Garrett D'Amore wrote: > I concur fully with Nico on this one. Further, customers requiring strict compliance can run an S10 zone. I think we're no longer in 1980's style SVID anymore -- already there have been other issues where we have deviated -- from certain ZFS semantics to packaging, so that we're no longer tracking SysV anymore. At the time that I left Sun, you could not successfully pass the UNIX conformance tests on a system with a ZFS root unless you were in a zone on a UFS filesystem due to issues with ZFS's handling of free and allocated block counts, and issues concerning recording timestamp updates at times required by the standards. But, you also could not pass the UNIX conformance tests in a zone due to the restrictions placed on creating and accessing devices when you're not in the global zone. So, unless something has changed that has not been made visible in an open ARC case, Solaris next will not provide any way to run UNIX '98 or UNIX '03 applications. (Not to mention that there appear to be no plans to implement SUSv4 conformance to keep up with the competition.) There was a lot of hand waving and statements made that ZFS and or zones could be fixed to provide a UNIX branded environment, but no plans were ever announced to make either of those possibilities a reality. - Don > > ... ... ... > > -- Garrett From iszczesniak@gmail.com Thu May 20 14:07:00 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KL70wo028899 for ; Thu, 20 May 2010 14:07:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KL6wJK026507 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:07:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00F1TLBOZ200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 15:07:00 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003RVLBN3N80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 15:06:59 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KL6wbW009384 for ; Thu, 20 May 2010 21:06:59 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-3759003 for PSARC-ext@sun.com; Thu, 20 May 2010 21:06:58 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-221176430 for PSARC-ext@sun.com; Thu, 20 May 2010 21:06:58 +0000 (Z) Received: from mail-fx0-f49.google.com ([209.85.161.49] [209.85.161.49]) by relay1i.sun.com with ESMTP id BT-MMP-8676269 for PSARC-ext@sun.com; Thu, 20 May 2010 21:06:58 +0000 (Z) Received: by fxm15 with SMTP id 15so324247fxm.8 for ; Thu, 20 May 2010 14:06:57 -0700 (PDT) Received: by 10.102.132.6 with SMTP id f6mr1035528mud.108.1274389617483; Thu, 20 May 2010 14:06:57 -0700 (PDT) Received: by 10.204.65.3 with HTTP; Thu, 20 May 2010 14:06:57 -0700 (PDT) Date: Thu, 20 May 2010 23:06:57 +0200 From: "I. Szczesniak" Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> To: Don Cragun Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZU6aIMRkXI32pOAxjOQd2yGEe1sqVHUvY1T9F75gH+U=; b=vn2DLkf9Xn/8ItNhE1OoCkWu3i8/8HE7pt42SQPCSxdj3D96mBxNOJ+gwrii2i4wcO x6pM5b1z09yxTb+c/eTNn5YEn7N6nKoYC1Lr4evy/tiXZTTRkSbkxTmV8KlKmwGxVx6r l45Q+i84S31IDgXp9FKVwoXIPnOAircar8K5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HmnXNOPhQKclyL2dX3OG9TbHtQMlK/2uPcP/RmYQhhNwiPKMnelhV+GxKteD5F65vj Lzc7sw/j4Wzw7CqQgVJFjRFsMxJbW+lPC3ahseDVmQ1qrX8wEvEicOFWfpzq9HPgXcrh YT/50cdeNcu3MfPATEHTpNEBC5nmmsAQc+ZaA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.061sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> Status: RO Content-Length: 1311 On Thu, May 20, 2010 at 9:18 PM, Don Cragun wrote: > The reason that LOGNAME_MAX was stuck at 8 in for so long > is that the System V ABIs and the SCDs require that value. > > Solaris 10 has been breaking ABI requirements around the edges for a > few years. Since this is case is departing from more ABI > requirements, should it have a major release binding? Or, should an > opinion be written for this case acknowledging that the ARC knows > that this case violates the ABIs and that the decision to do so is > intentional (without setting precedent to otherwise ignore the ABI)? > > Once upon a time, there was a gang of four working on a > definition of what would be the limits of the changes going into > "Solaris next", whether it would be classified as a major or minor > release, and what would constitute the basis for determining whether > or not an implementation of OpenSolaris would be able to use the > Solaris trademark. Was a report ever produced by the gang? (I know > that at least half of the gang no longer works for Sun/Oracle.) Is > there any current plan to define any type of new Solaris ABI? I agree with Don that at *least* an opinion must be written for such a change. You will at least break major software like Informix with this change. Irek From garrett.damore@oracle.com Thu May 20 14:25:55 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KLPtv9029200 for ; Thu, 20 May 2010 14:25:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KLPsO1024620 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 14:25:55 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q0060PM765V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:25:54 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00BXQM74NL50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 14:25:52 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KLPpm8015617 for ; Thu, 20 May 2010 21:25:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KLPmqV013307; Thu, 20 May 2010 21:25:48 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 255466291274390682; Thu, 20 May 2010 14:24:42 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 14:24:42 -0700 Date: Thu, 20 May 2010 14:24:41 -0700 From: "Garrett D'Amore" Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: To: "I. Szczesniak" Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4BF5A899.2020905@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BF5A8DD.001A:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2204 On 05/20/10 02:06 PM, I. Szczesniak wrote: > On Thu, May 20, 2010 at 9:18 PM, Don Cragun wrote: > >> The reason that LOGNAME_MAX was stuck at 8 in for so long >> is that the System V ABIs and the SCDs require that value. >> >> Solaris 10 has been breaking ABI requirements around the edges for a >> few years. Since this is case is departing from more ABI >> requirements, should it have a major release binding? Or, should an >> opinion be written for this case acknowledging that the ARC knows >> that this case violates the ABIs and that the decision to do so is >> intentional (without setting precedent to otherwise ignore the ABI)? >> >> Once upon a time, there was a gang of four working on a >> definition of what would be the limits of the changes going into >> "Solaris next", whether it would be classified as a major or minor >> release, and what would constitute the basis for determining whether >> or not an implementation of OpenSolaris would be able to use the >> Solaris trademark. Was a report ever produced by the gang? (I know >> that at least half of the gang no longer works for Sun/Oracle.) Is >> there any current plan to define any type of new Solaris ABI? >> > I agree with Don that at *least* an opinion must be written for such a > change. You will at least break major software like Informix with this > change. > Huh? I'm not disagreeing that an opinion is warranted, but it seems to me that we're lifting a restriction; whether software is busted or not as a consequence depends on whether a) the software is coded properly to inquire about limits using the proper APIs. b) the site has chosen to exercise longer usernames Both must be true for rationale cases of breakage. Of course there is an irrationale case as well: c) software inquiries the limit, but is defective and unable to handle a value other than the legacy one (for example by using a fixed size array, but bzeroing the array using the results of the inquiry to determine the length!) Obviously such software would be so horrendously buggy that we can't possibly be held accountable for this kind of breakage. - Garrett > Irek > From dcragun@sonic.net Thu May 20 19:52:04 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L2q4bc004093 for ; Thu, 20 May 2010 19:52:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4L2q3q6034521 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 20:52:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0030L1ARKE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 19:52:03 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R000JQ1AQOLE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 19:52:02 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L2q1HN003073 for ; Fri, 21 May 2010 02:52:01 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-100824 for PSARC-ext@sun.com; Fri, 21 May 2010 02:52:01 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-165769017 for PSARC-ext@sun.com; Fri, 21 May 2010 02:52:01 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-12014913 for PSARC-ext@sun.com; Fri, 21 May 2010 02:52:00 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4L2puoH016820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 May 2010 19:51:57 -0700 Date: Thu, 20 May 2010 19:51:56 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF5A899.2020905@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.120sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> Status: RO Content-Length: 4225 On May 20, 2010, at 2:24 PM, Garrett D'Amore wrote: > On 05/20/10 02:06 PM, I. Szczesniak wrote: >> On Thu, May 20, 2010 at 9:18 PM, Don Cragun wrote: >> >>> The reason that LOGNAME_MAX was stuck at 8 in for so long >>> is that the System V ABIs and the SCDs require that value. >>> >>> Solaris 10 has been breaking ABI requirements around the edges for a >>> few years. Since this is case is departing from more ABI >>> requirements, should it have a major release binding? Or, should an >>> opinion be written for this case acknowledging that the ARC knows >>> that this case violates the ABIs and that the decision to do so is >>> intentional (without setting precedent to otherwise ignore the ABI)? >>> >>> Once upon a time, there was a gang of four working on a >>> definition of what would be the limits of the changes going into >>> "Solaris next", whether it would be classified as a major or minor >>> release, and what would constitute the basis for determining whether >>> or not an implementation of OpenSolaris would be able to use the >>> Solaris trademark. Was a report ever produced by the gang? (I know >>> that at least half of the gang no longer works for Sun/Oracle.) Is >>> there any current plan to define any type of new Solaris ABI? >>> >> I agree with Don that at *least* an opinion must be written for such a >> change. You will at least break major software like Informix with this >> change. >> > > Huh? > > I'm not disagreeing that an opinion is warranted, but it seems to me that we're lifting a restriction; whether software is busted or not as a consequence depends on whether > > a) the software is coded properly to inquire about limits using the proper APIs. According to the Solaris 10 limits.h(3HEAD) man page, LOGNAME_MAX is an invariant value defined in . It is described there as: "The maximum number of bytes supported in a user's login name." So it is perfectly legitimate for a Solaris 10 application to define an array as char logname[LOGNAME_MAX + 1] and copy an entry from a struct passwd using strncpy(logname, pwd.pw_name, LOGNAME_MAX); logname[LOGNAME_MAX] = '\0'; and know that it has copied the entire user's login name out of the struct passwd. Programs aren't usually supposed to have to be rebuilt for a Solaris minor release to continue working. That is why I originally questioned whether this change should have a major release binding. Note also that the value of LOGIN_NAME_MAX is specified to be 9 in Oracle's (and Fujitsu's) UNIX '98 and UNIX '03 branding CSQs. If you're going to change this value, Oracle will need to file for a new UNIX brand and pay the associated branding fees to TOG. If Fujitsu is still partnering with Oracle to provide a Solaris OS for Fujitsu hardware, you will also need to notify Fujitsu that they'll need to rebrand as well. (There are ways around this if sysconf() returns different values for different programming environments, but if you do that you will break strictly conforming applications if you allow longer login names to be visible to applications built using the current SUSv2 and SUSv3 programming environments. > b) the site has chosen to exercise longer usernames > > Both must be true for rationale cases of breakage. Of course there is an irrationale case as well: > > c) software inquiries the limit, but is defective and unable to handle a value other than the legacy one (for example by using a fixed size array, but bzeroing the array using the results of the inquiry to determine the length!) Obviously such software would be so horrendously buggy that we can't possibly be held accountable for this kind of breakage. Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a "Conforming POSIX Application Using Extensions" is free to use LOGNAME_MAX as defined in as long as it documents that it uses this macro (and __EXTENSIONS__ as defined on the standards(5) man page). You may wish that applications wouldn't do that, but according to the standards, using documented features of an implementation is not a bug; it just makes the program source less portable. - Don > - Garrett > >> Irek >> > From carlsonj@workingcode.com Thu May 20 19:57:41 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L2vek9004458 for ; Thu, 20 May 2010 19:57:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4L2vefN036722 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 20:57:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R006051K4C300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 19:57:40 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00D0X1K3N0D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 19:57:39 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4L2vYB6012015 for ; Fri, 21 May 2010 02:57:39 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-1697129 for PSARC-ext@sun.com; Fri, 21 May 2010 02:57:34 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-219674310 for PSARC-ext@sun.com; Fri, 21 May 2010 02:57:34 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-33692281 for PSARC-ext@sun.com; Fri, 21 May 2010 02:57:33 +0000 (Z) Received: from dhcp-226.workingcode.com (dhcp-226 [192.168.254.226]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4L2vOs1021472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 22:57:24 -0400 (EDT) Date: Thu, 20 May 2010 22:57:24 -0400 From: James Carlson Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF5A899.2020905@oracle.com> To: "Garrett D'Amore" Cc: "I. Szczesniak" , PSARC-ext@sun.com, Don Cragun Message-id: <4BF5F694.9030207@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Enigmail-Version: 1.0.1 X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.323sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 1604 On 5/20/10 5:24 PM, Garrett D'Amore wrote: > On 05/20/10 02:06 PM, I. Szczesniak wrote: >> I agree with Don that at *least* an opinion must be written for such a >> change. You will at least break major software like Informix with this >> change. >> > > Huh? > > I'm not disagreeing that an opinion is warranted, but it seems to me > that we're lifting a restriction; whether software is busted or not as a > consequence depends on whether > > a) the software is coded properly to inquire about limits using the > proper APIs. > b) the site has chosen to exercise longer usernames > > Both must be true for rationale cases of breakage. Of course there is > an irrationale case as well: > > c) software inquiries the limit, but is defective and unable to handle a > value other than the legacy one (for example by using a fixed size > array, but bzeroing the array using the results of the inquiry to > determine the length!) Obviously such software would be so horrendously > buggy that we can't possibly be held accountable for this kind of breakage. There is one other case: object code compiled using the #define to size an array is linked (either dynamically or otherwise) with object code that was previously compiled with a different value for that #define. I'm pretty sure that's why it's an ABI issue. Of course, I welcome the change, and I'd be quite surprised if Informix up 'n fell over on it. It's about danged time. I'm sure Mr. Sommerfe and the Legions of the Truncated Surnames will agree. ;-} -- James Carlson 42.703N 71.076W From bill.sommerfeld@oracle.com Thu May 20 21:16:44 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L4GiRc005519 for ; Thu, 20 May 2010 21:16:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L4Ggx0017027 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 21:16:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0040357S6800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 21:16:40 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R003KI57RL700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 21:16:39 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4L4GdT9014684 for ; Fri, 21 May 2010 04:16:39 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L4GZfH019521; Fri, 21 May 2010 04:16:35 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 286710501274415376; Thu, 20 May 2010 21:16:16 -0700 Received: from [10.7.251.192] (/10.7.251.192) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 21:16:16 -0700 Date: Thu, 20 May 2010 21:16:15 -0700 From: Bill Sommerfeld Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF5F694.9030207@workingcode.com> To: James Carlson Cc: "Garrett D'Amore" , "I. Szczesniak" , PSARC-ext@sun.com, Don Cragun Message-id: <4BF6090F.60007@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BF60924.0094:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <4BF5F694.9030207@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1708 On 05/20/10 19:57, James Carlson wrote: > Of course, I welcome the change, and I'd be quite surprised if Informix > up 'n fell over on it. It's about danged time. I'm sure Mr. Sommerfe > and the Legions of the Truncated Surnames will agree. ;-} Indeed. Where possible, I've been running with a 10-character username in /etc/passwd since I started at sun in 2000 ; I've also verified that this works in NIS. I've run into surprisingly few bugs. More than a few deltas in the teamware/SCCS sources used for solaris 10 and earlier were created by the user "sommerfeld". Nothing in solaris 8 or later (and I haven't verified earlier releases) prevents an application from seeing a longer-than-LOGNAME_MAX string from pwd.pw_name. What's more, administrators who use "useradd" to add a user with a long name will see a warning message, but the user will be added to /etc/passwd file anyway. So nothing compiled into the code enforces an 8-character maximum today if a system administrator chooses to use longer usernames; all that really remains of the limit is the attractive nuisance of LOGNAME_MAX. One alternative that I haven't fully explored is to (conditionally or unconditionally) delete LOGNAME_MAX from limits.h, forcing applications to rely on the dynamic size returned by sysconf(). We have long recognized an exception to the backwards compatibility requirements when an interface contains an inherent risk of data corruption, and that seems to be evident here; given that an alternative interface exists (sysconf(_SC_LOGIN_NAME_MAX)), and also given the prevalence of other systems which don't bother to define LOGNAME_MAX, this may well be a safer path. - Bill From bill.sommerfeld@oracle.com Thu May 20 21:42:13 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L4gDGQ005604 for ; Thu, 20 May 2010 21:42:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L4gDHC004078 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 May 2010 23:42:13 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00D036EC8V00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 22:42:12 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R003O26ECZ8D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 May 2010 22:42:12 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4L4gBU3019372 for ; Fri, 21 May 2010 04:42:12 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L4g8SS005872; Fri, 21 May 2010 04:42:09 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 256272701274416874; Thu, 20 May 2010 21:41:14 -0700 Received: from [10.7.251.192] (/10.7.251.192) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 21:41:14 -0700 Date: Thu, 20 May 2010 21:41:13 -0700 From: Bill Sommerfeld Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> To: Don Cragun Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4BF60EE9.4070608@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4BF60F21.01B3:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 465 On 05/20/10 19:51, Don Cragun wrote: > (... but if you > do that you will break strictly conforming applications if you > allow longer login names to be visible to applications built using > the current SUSv2 and SUSv3 programming environments. But this would not be new behavior. Today, solaris permits longer login names to be visible to applications built using the current SUSv2 and SUSv3 environments if an administrator adds such a user. - Bill From Darren.Moffat@oracle.com Fri May 21 01:20:25 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L8KP96000723 for ; Fri, 21 May 2010 01:20:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L8KM4W006349 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 03:20:24 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00K7HGHZWY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:20:23 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00IEZGHP5N20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:20:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L8KCeg000883 for ; Fri, 21 May 2010 08:20:13 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L8K90e007178; Fri, 21 May 2010 08:20:10 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 287169221274429928; Fri, 21 May 2010 01:18:48 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 01:18:48 -0700 Date: Fri, 21 May 2010 09:18:46 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> To: Don Cragun Cc: PSARC-ext@sun.com Message-id: <4BF641E6.8060600@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BF6423B.000B:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 444 On 20/05/2010 21:37, Don Cragun wrote: > I'm not disagreeing with the move to 32 bytes. I just believe that the > ARC needs to make it clear that doing so is a conscious decision to break > the ABIs and that it does not set a precedent for other ABI breakage. If > I remember correctly, an opinion needs to be written to do that even if > this is just a fast track case. No opinion is needed, this case alone is enough. -- Darren J Moffat From Darren.Moffat@Oracle.COM Fri May 21 01:20:52 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L8KqMn000735 for ; Fri, 21 May 2010 01:20:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4L8Kp18054657 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 02:20:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00L03GIR7900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:20:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00I28GIM5L20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:20:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L8Kjkg012913 for ; Fri, 21 May 2010 08:20:45 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L8KdVq006687; Fri, 21 May 2010 08:20:40 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 256733351274429976; Fri, 21 May 2010 01:19:36 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 01:19:36 -0700 Date: Fri, 21 May 2010 09:19:33 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <20100520204554.GW9605@oracle.com> To: Nicolas Williams Cc: Alan Coopersmith , Don Cragun , PSARC-ext@sun.com Message-id: <4BF64215.9000209@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BF64259.004A:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <4BF59EB6.9060609@oracle.com> <20100520204554.GW9605@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1195 On 20/05/2010 21:45, Nicolas Williams wrote: > On Thu, May 20, 2010 at 01:42:30PM -0700, Alan Coopersmith wrote: >> Nicolas Williams wrote: >>> In any case, customers that require strict SysV ABI compliance (e.g., >>> customers that have apps that use LOGNAME_MAX and/or L_cuserid and who >>> cannot or will not re-build those apps) can always stick to creating >>> usernames with 8 or fewer bytes. >> >> If that is to be a supported scenario, then all system provided account >> names should remain within the 8 character limit. Obviously they already >> have to for any case requesting a patch binding for possible backport to >> an older release, but ARC should decide whether cases that only deliver >> after this change should be able to add system accounts with longer usernames >> ("postgresql" instead of "postgres" for instance). > > Not necessarily. We could have pkgs that will only work in a > non-standards-compliant installation. Certainly in /contrib :) > > But, yes, I agree. This could be enforced by IPS or checked for by the > recently proposed IPS lint checker. I suspect Darren will claim all of > that is "not this case". Exactly not this case. -- Darren J Moffat From Darren.Moffat@oracle.com Fri May 21 01:24:36 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L8OaFI000775 for ; Fri, 21 May 2010 01:24:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L8OXwR008704 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 03:24:36 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0010RGOY1D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:24:34 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00741GOXWLD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:24:33 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L8OWmM008604 for ; Fri, 21 May 2010 08:24:33 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L8OPbv022447; Fri, 21 May 2010 08:24:25 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 287179941274430246; Fri, 21 May 2010 01:24:06 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 01:24:06 -0700 Date: Fri, 21 May 2010 09:24:03 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: To: "I. Szczesniak" Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4BF64323.7070809@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF6433C.006A:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 2088 On 20/05/2010 22:06, I. Szczesniak wrote: > On Thu, May 20, 2010 at 9:18 PM, Don Cragun wrote: >> The reason that LOGNAME_MAX was stuck at 8 in for so long >> is that the System V ABIs and the SCDs require that value. >> >> Solaris 10 has been breaking ABI requirements around the edges for a >> few years. Since this is case is departing from more ABI >> requirements, should it have a major release binding? Or, should an >> opinion be written for this case acknowledging that the ARC knows >> that this case violates the ABIs and that the decision to do so is >> intentional (without setting precedent to otherwise ignore the ABI)? >> >> Once upon a time, there was a gang of four working on a >> definition of what would be the limits of the changes going into >> "Solaris next", whether it would be classified as a major or minor >> release, and what would constitute the basis for determining whether >> or not an implementation of OpenSolaris would be able to use the >> Solaris trademark. Was a report ever produced by the gang? (I know >> that at least half of the gang no longer works for Sun/Oracle.) Is >> there any current plan to define any type of new Solaris ABI? > > I agree with Don that at *least* an opinion must be written for such a > change. You will at least break major software like Informix with this > change. No opinion will be written unless a full voting ARC member derails the case and takes ownership of it. Note that having an ARC opinion doesn't fix anything all it does is put exactly the same material that is in the fast-track into an opinion document. Which given how simple this case actually is gains nothing. Remeber this change has minor release binding, that makes Informix and anything else that depends on the existing behaviour will still run on Solaris 10 and will still run on OpenSolaris in an S10C zone. If 3rd party applications are broken by OpenSolaris changing to match what other UNIX or UNIXlike systems do already then maybe they aren't using the proper APIs. -- Darren J Moffat From Darren.Moffat@Oracle.COM Fri May 21 01:26:41 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L8QfiC000791 for ; Fri, 21 May 2010 01:26:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L8QeZO009642 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 03:26:41 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00103GSG4X00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:26:40 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R007AQGSGWIC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:26:40 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L8Qd2k014875; Fri, 21 May 2010 08:26:39 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L5aUqC028365; Fri, 21 May 2010 08:26:23 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 287185121274430376; Fri, 21 May 2010 01:26:16 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 01:26:15 -0700 Date: Fri, 21 May 2010 09:26:13 +0100 From: Darren J Moffat Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: To: Roland Mainz Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4BF643A5.1020705@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF643B7.0126:SCFMA4539814,ss=1,fgs=0 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1677 On 20/05/2010 18:50, Roland Mainz wrote: >> Solaris currently documents a maximum username length of 8 characters >> in passwd(4). > > Erm... AFAIK this should be _bytes_, not characters. Characters would > be multibyte characters in this context with the small twist that It is a effectively a 'char username[32]'. > tools like Solaris's tools like "useradd" always restricted this to > the ASCII character set while many sites allow (by using their own set > of tools) non-ASCII usernames (e.g. German umlauts are commonly used > on German university sites and some japanese customers have been using > Japanese characters for some time) and other operating systems even > allow a larger set of multibyte characters to be used. > IMO this case should either allow the use of multibyte characters or > expcitly refer to bytes/ASCII characters (see below). This is is not being extended to support multibyte usernames. > > I would give this case (if I could) a +1 with two minor changes: > 1. "useradd" should clamp the string to 32bytes but _validate_ that > the input username doesn't get any multibyte characters cut-off in the > middle. No, it doesn't do that today and that is out of scope for this case. > 2. "useradd" should print a warning if non-ASCII characters (e.g. > umlauts in ISO 8859-1/15) or multibyte characters are used unless a > specific option is provided (e.g. -W) > This is easy to do... if you don't have time I can volunteer to do > this modification. It isn't that I don't have time it is out of scope. This case is about one single thing, changing the current limit of 8 to 32. It won't be extended to anything else. -- Darren J Moffat From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri May 21 01:57:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L8vZAi001226 for ; Fri, 21 May 2010 01:57:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4L8vYvI009235 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 02:57:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0020RI7ZLS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:57:35 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R007L4I7XWEE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 01:57:34 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L8vWC2026038 for ; Fri, 21 May 2010 08:57:32 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-1713788 for PSARC-ext@sun.com; Fri, 21 May 2010 08:55:32 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-164420640 for PSARC-ext@sun.com; Fri, 21 May 2010 08:55:29 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-11018196 for PSARC-ext@sun.com; Fri, 21 May 2010 08:55:29 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 6F3E363C1A5; Fri, 21 May 2010 10:55:27 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 4311363C1A2; Fri, 21 May 2010 10:55:23 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o4L8tNuw011129; Fri, 21 May 2010 10:55:23 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 10:55:23 +0200 Date: Fri, 21 May 2010 10:55:23 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: garrett.damore@oracle.com, dcragun@sonic.net Cc: PSARC-ext@sun.com Message-id: <4bf64a7b.vCtm7WNiK6kvSj32%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 2.391sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 21 May 2010 08:55:23.0331 (UTC) FILETIME=[59425130:01CAF8C3] Status: RO Content-Length: 2397 Don Cragun wrote: > According to the Solaris 10 limits.h(3HEAD) man page, LOGNAME_MAX is an > invariant value defined in . It is described there as: > "The maximum number of bytes supported in a user's login name." > > So it is perfectly legitimate for a Solaris 10 application to define > an array as char logname[LOGNAME_MAX + 1] and copy an entry from a > struct passwd using > strncpy(logname, pwd.pw_name, LOGNAME_MAX); > logname[LOGNAME_MAX] = '\0'; > and know that it has copied the entire user's login name out of the > struct passwd. Programs aren't usually supposed to have to be rebuilt > for a Solaris minor release to continue working. That is why I > originally questioned whether this change should have a major release > binding. > > Note also that the value of LOGIN_NAME_MAX is specified to be 9 in > Oracle's (and Fujitsu's) UNIX '98 and UNIX '03 branding CSQs. If > you're going to change this value, Oracle will need to file for a new > UNIX brand and pay the associated branding fees to TOG. If Fujitsu A quick check for users of the definition LOGNAME_MAX shows that no parts of Solaris that are relevant regarding to interfaces use this definition. There are however places like ./lib/libsec/common/acltext.c where this devinition definitely should not be used. The definition LOGNAME_MAX was used in the "utmp" and "wtmp" files with binary compatibility for AT&T UNIX versions from the 1970s in /var/adm/. These files have been used with larger limits in SunOS-3.x already and SunOS-5.x introduced "utmpx" and "wtmpx" files with the previous *BSD definitiony since 20 years. The old files are no longer in use with current Solaris version. There is a POSIX definition related to user name lenght in http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html uname and gname fields have 32 octets. This is the same value as used in the "utmpx" and "wtmpx" files. I recommend to look into the Solaris sources and fix the parts that still historically or by accident as in ./lib/libsec/common/acltext.c use a lower limit. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri May 21 02:08:42 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L98gfF001388 for ; Fri, 21 May 2010 02:08:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L98eaU000921 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 04:08:41 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0090PIQHMD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 02:08:41 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00IWKIQG5L80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 02:08:40 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4L93x9J019111 for ; Fri, 21 May 2010 09:08:40 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay41i.sun.com with ESMTP id BT-MMP-1714409 for PSARC-ext@sun.com; Fri, 21 May 2010 09:08:29 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-164801860 for PSARC-ext@sun.com; Fri, 21 May 2010 09:08:28 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-5049620 for PSARC-ext@sun.com; Fri, 21 May 2010 09:08:28 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B89867D4023; Fri, 21 May 2010 11:08:26 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 99A1D7D4030; Fri, 21 May 2010 11:08:25 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o4L98QsQ011658; Fri, 21 May 2010 11:08:26 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 11:08:25 +0200 Date: Fri, 21 May 2010 11:08:25 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF641E6.8060600@Oracle.COM> Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: dcragun@sonic.net, Darren.Moffat@oracle.com Cc: PSARC-ext@sun.com Message-id: <4bf64d89.e7XH/t6ob/3wYgjx%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.625sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> <4BF641E6.8060600@Oracle.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 21 May 2010 09:08:25.0722 (UTC) FILETIME=[2B99B5A0:01CAF8C5] Status: RO Content-Length: 915 Darren J Moffat wrote: > On 20/05/2010 21:37, Don Cragun wrote: > > I'm not disagreeing with the move to 32 bytes. I just believe that the > > ARC needs to make it clear that doing so is a conscious decision to break > > the ABIs and that it does not set a precedent for other ABI breakage. If > > I remember correctly, an opinion needs to be written to do that even if > > this is just a fast track case. > > No opinion is needed, this case alone is enough. Well, as mentioned before, the ABIs related to 8 char user names have already been removed from Solaris (IIRC with Solaris 8). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri May 21 02:53:26 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4L9rQRX001583 for ; Fri, 21 May 2010 02:53:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4L9rOuL005778 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 02:53:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00K0TKT1VH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 02:53:25 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00K02KSMWT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 02:53:10 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4L9r4LH006108 for ; Fri, 21 May 2010 09:53:09 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-2314392 for PSARC-ext@sun.com; Fri, 21 May 2010 09:53:04 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-222282011 for PSARC-ext@sun.com; Fri, 21 May 2010 09:53:03 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-34408553 for PSARC-ext@sun.com; Fri, 21 May 2010 09:53:03 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 196BD6F06FE; Fri, 21 May 2010 11:53:02 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 385B66F06BD; Fri, 21 May 2010 11:53:01 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o4L9r1tc012897; Fri, 21 May 2010 11:53:01 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 11:53:00 +0200 Date: Fri, 21 May 2010 11:53:01 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: roland.mainz@nrubsig.org, darrenm@sac.sfbay.sun.com Cc: PSARC-ext@sun.com Message-id: <4bf657fd.Fe5H37c4pth2j0u6%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.329sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 21 May 2010 09:53:00.0909 (UTC) FILETIME=[6622D9D0:01CAF8CB] Status: RO Content-Length: 994 Roland Mainz wrote: > I would give this case (if I could) a +1 with two minor changes: > 1. "useradd" should clamp the string to 32bytes but _validate_ that > the input username doesn't get any multibyte characters cut-off in the > middle. As we are in the 21st century, we could even support longer names. The 32 char limit is from POSIX.1-1988. > 2. "useradd" should print a warning if non-ASCII characters (e.g. > umlauts in ISO 8859-1/15) or multibyte characters are used unless a > specific option is provided (e.g. -W) > This is easy to do... if you don't have time I can volunteer to do > this modification. POSIX explicitly permits non-US-ascii login names. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@oracle.com Fri May 21 03:11:29 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LABTwT002034 for ; Fri, 21 May 2010 03:11:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LABRa1049116 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 04:11:29 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0060PLN47E00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 03:11:28 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R003U9LN1KV20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 03:11:26 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LABPQw024421 for ; Fri, 21 May 2010 10:11:25 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4L9GhhR026474; Fri, 21 May 2010 10:11:21 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 287428951274436584; Fri, 21 May 2010 03:09:44 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 03:09:44 -0700 Date: Fri, 21 May 2010 11:09:41 +0100 From: Darren J Moffat Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <4bf657fd.Fe5H37c4pth2j0u6%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de Cc: roland.mainz@nrubsig.org, PSARC-ext@sun.com Message-id: <4BF65BE5.8000108@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BF65C4A.0003:SCFMA4539814,ss=1,fgs=0 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> <4bf657fd.Fe5H37c4pth2j0u6%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1414 On 21/05/2010 10:53, Joerg.Schilling@fokus.fraunhofer.de wrote: > Roland Mainz wrote: > >> I would give this case (if I could) a +1 with two minor changes: >> 1. "useradd" should clamp the string to 32bytes but _validate_ that >> the input username doesn't get any multibyte characters cut-off in the >> middle. > > As we are in the 21st century, we could even support longer names. > The 32 char limit is from POSIX.1-1988. We could but they would be truncated in utmpx, so going beyond 32 requires changing utmpx to have a longer ut_user field and that will break a lot of things. This is case is intended to be simple and to make official that fact that most of Solaris already works just fine with 32 rather than 8. >> 2. "useradd" should print a warning if non-ASCII characters (e.g. >> umlauts in ISO 8859-1/15) or multibyte characters are used unless a >> specific option is provided (e.g. -W) >> This is easy to do... if you don't have time I can volunteer to do >> this modification. > > POSIX explicitly permits non-US-ascii login names. Wither POSIX allows it or not isn't relevant to this case. I am not extending this case to change what we do don't support about non-US-ASCII long names. This case is about one simple thing, changing the existing documented value of 8 to 32 and fixing the appropriate sysconf(3C) interfaces to match that. -- Darren J Moffat From carlsonj@workingcode.com Fri May 21 04:20:47 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LBKkd7003437 for ; Fri, 21 May 2010 04:20:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LBKkdr002860 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 06:20:46 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00J03OUMKL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 04:20:46 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00KPJOULWP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 04:20:45 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LBKiVn028947 for ; Fri, 21 May 2010 11:20:44 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-949086 for PSARC-ext@sun.com; Fri, 21 May 2010 11:20:44 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-222437125 for PSARC-ext@sun.com; Fri, 21 May 2010 11:20:44 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-10158153 for PSARC-ext@sun.com; Fri, 21 May 2010 11:20:43 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4LBKZNZ025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 07:20:35 -0400 (EDT) Date: Fri, 21 May 2010 07:20:35 -0400 From: James Carlson Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> To: Don Cragun Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4BF66C83.8040902@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.322sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1180 On 05/20/10 22:51, Don Cragun wrote: > Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a > "Conforming POSIX Application Using Extensions" is free to use > LOGNAME_MAX as defined in as long as it documents that it > uses this macro (and __EXTENSIONS__ as defined on the standards(5) > man page). You may wish that applications wouldn't do that, but > according to the standards, using documented features of an > implementation is not a bug; it just makes the program source less > portable. That only counts when in such an environment, though. A reasonable solution (borrowing from Bill's suggestion) would be to have LOGNAME_MAX defined as 9 when in a conforming environment, and intentionally undefined elsewhere. That way, conforming applications will still do what they've always done, and since Solaris has actually supported long user names for a long time, the same risks apply to using them. Non-conforming applications will see a change, but one for the better: if they mistakenly used LOGNAME_MAX, they'll need to recode in order to recompile in the future. -- James Carlson 42.703N 71.076W From Darren.Moffat@oracle.com Fri May 21 05:41:26 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LCfQbc004201 for ; Fri, 21 May 2010 05:41:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LCfPhh021769 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 05:41:25 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00A0FSL18S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:41:25 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00IFHSL0R170@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:41:24 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4LCfNhG018211 for ; Fri, 21 May 2010 12:41:24 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LBt3mw001125; Fri, 21 May 2010 12:41:19 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 287755291274445633; Fri, 21 May 2010 05:40:33 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 05:40:33 -0700 Date: Fri, 21 May 2010 13:40:30 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF66C83.8040902@workingcode.com> To: James Carlson Cc: Don Cragun , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4BF67F3E.4020009@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BF67F70.0087:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> <4BF66C83.8040902@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1235 On 21/05/2010 12:20, James Carlson wrote: > On 05/20/10 22:51, Don Cragun wrote: >> Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a >> "Conforming POSIX Application Using Extensions" is free to use >> LOGNAME_MAX as defined in as long as it documents that it >> uses this macro (and __EXTENSIONS__ as defined on the standards(5) >> man page). You may wish that applications wouldn't do that, but >> according to the standards, using documented features of an >> implementation is not a bug; it just makes the program source less >> portable. > > That only counts when in such an environment, though. A reasonable > solution (borrowing from Bill's suggestion) would be to have LOGNAME_MAX > defined as 9 when in a conforming environment, and intentionally > undefined elsewhere. No I don't think that is reasonable, because it will only cause to create applications that can only deal with shorter usernames which will be different to the rest of the system. For the #define it will only come into play if the application is recompiled on a release with this change. Ultimately this just causes problems for users and admins. This case has minor release binding for a reason. -- Darren J Moffat From Darren.Moffat@oracle.com Fri May 21 06:16:51 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LDGoLJ004660 for ; Fri, 21 May 2010 06:16:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LDGoi9014049 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 07:16:50 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00F07U82FO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:16:50 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R0034KU81L5D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:16:49 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LDGmFt000222 for ; Fri, 21 May 2010 13:16:48 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KMd1SD018210; Fri, 21 May 2010 13:16:39 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 257410521274447734; Fri, 21 May 2010 06:15:34 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 06:15:34 -0700 Date: Fri, 21 May 2010 14:15:31 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4bf64a7b.vCtm7WNiK6kvSj32%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de Cc: garrett.damore@oracle.com, dcragun@sonic.net, PSARC-ext@sun.com Message-id: <4BF68773.807@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BF687B8.001D:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> <4bf64a7b.vCtm7WNiK6kvSj32%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 518 On 21/05/2010 09:55, Joerg.Schilling@fokus.fraunhofer.de wrote: > I recommend to look into the Solaris sources and fix the parts that still > historically or by accident as in ./lib/libsec/common/acltext.c use a lower > limit. Thanks Joerg, that was one I hadn't found yet in my testing since I hadn't moved on to archivers yet. acltotext(3SEC) is indeed broken and will currently display up to 19 bytes of username in some cases. That one will be fixed with the integration of this project. -- Darren J Moffat From carlsonj@workingcode.com Fri May 21 08:31:47 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LFVl6E007086 for ; Fri, 21 May 2010 08:31:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LFVhxe001549 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 08:31:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0010H0GY5000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 21 May 2010 09:31:46 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00KGE0GX5P30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 21 May 2010 09:31:45 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LF9rPD010432 for ; Fri, 21 May 2010 15:31:44 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-1729148 for PSARC-ext@Sun.COM; Fri, 21 May 2010 15:31:44 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-223201495 for PSARC-ext@Sun.COM; Fri, 21 May 2010 15:31:43 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-10725327 for PSARC-ext@Sun.COM; Fri, 21 May 2010 15:31:42 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4LFV5eh028814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 11:31:08 -0400 (EDT) Date: Fri, 21 May 2010 11:31:04 -0400 From: James Carlson Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF67F3E.4020009@Oracle.COM> To: Darren J Moffat Cc: Don Cragun , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4BF6A738.4070802@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-z.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.663sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> <4BF66C83.8040902@workingcode.com> <4BF67F3E.4020009@Oracle.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1962 Darren J Moffat wrote: > On 21/05/2010 12:20, James Carlson wrote: >> On 05/20/10 22:51, Don Cragun wrote: >>> Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a >>> "Conforming POSIX Application Using Extensions" is free to use >>> LOGNAME_MAX as defined in as long as it documents that it >>> uses this macro (and __EXTENSIONS__ as defined on the standards(5) >>> man page). You may wish that applications wouldn't do that, but >>> according to the standards, using documented features of an >>> implementation is not a bug; it just makes the program source less >>> portable. >> >> That only counts when in such an environment, though. A reasonable >> solution (borrowing from Bill's suggestion) would be to have LOGNAME_MAX >> defined as 9 when in a conforming environment, and intentionally >> undefined elsewhere. > > No I don't think that is reasonable, because it will only cause to > create applications that can only deal with shorter usernames which will > be different to the rest of the system. For the #define it will only > come into play if the application is recompiled on a release with this > change. Ultimately this just causes problems for users and admins. It preserves the existing branding, allows "normal" applications to be improved, and permits those who feel they need strict conformance to get it. You can't have everything. > This case has minor release binding for a reason. I don't think anybody was ignoring the Minor release binding. I see nothing in the definition of "Committed" that allows incompatible change in a Minor release without an EOF, so I think what you may actually be asking for is the quasi-Major-like intentions of OpenSolaris/Indiana. No problem there, but the issues still aren't trivial, which is why this wasn't done in the past. It's not like we lacked Minor release vehicles 10 years ago. -- James Carlson 42.703N 71.076W From doug.leavitt@oracle.com Fri May 21 08:32:41 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LFWflw007116 for ; Fri, 21 May 2010 08:32:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LFWcdR008827 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 10:32:41 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S00L1T0IGCV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 08:32:40 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00H0W0IFQE50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 08:32:39 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LFWdbw018039 for ; Fri, 21 May 2010 15:32:39 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LFWX7h005860; Fri, 21 May 2010 15:32:34 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 288264711274455885; Fri, 21 May 2010 08:31:25 -0700 Received: from [10.7.251.243] (/10.7.251.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 08:31:25 -0700 Date: Fri, 21 May 2010 10:31:23 -0500 From: Doug Leavitt Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF6090F.60007@oracle.com> To: Bill Sommerfeld Cc: James Carlson , "Garrett D'Amore" , "I. Szczesniak" , PSARC-ext@sun.com, Don Cragun Message-id: <4BF6A74B.70507@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BF6A793.0129:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <4BF5F694.9030207@workingcode.com> <4BF6090F.60007@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre6 Thunderbird/3.0.3 Status: RO Content-Length: 2543 Just FYI: I can confirm what Bill points out below. Solaris naming services does not intentionally impose a limits on the length of username (or any other variable length strings like gecos etc.). NIS currently still has a 4k buffer max, so a NIS passwd entry total length has that upwards boundary. Also we do impose another max buffer size at 128K, such as when you do a getpwnam_r or similar API call and are using caching (nscd). Beyond that things like files line length or LDAP uid=name are bounded by outside forces such as the maximum size of a vi line buffer or a specific LDAP schema/server limit. Anything (in name services) contradicting this is considered a name services bug. Doug. On 05/20/10 11:16 PM, Bill Sommerfeld wrote: > On 05/20/10 19:57, James Carlson wrote: >> Of course, I welcome the change, and I'd be quite surprised if Informix >> up 'n fell over on it. It's about danged time. I'm sure Mr. Sommerfe >> and the Legions of the Truncated Surnames will agree. ;-} > > Indeed. > > Where possible, I've been running with a 10-character username in > /etc/passwd since I started at sun in 2000 ; I've also verified that > this works in NIS. I've run into surprisingly few bugs. More than a > few deltas in the teamware/SCCS sources used for solaris 10 and > earlier were created by the user "sommerfeld". > > Nothing in solaris 8 or later (and I haven't verified earlier > releases) prevents an application from seeing a > longer-than-LOGNAME_MAX string from pwd.pw_name. > > What's more, administrators who use "useradd" to add a user with a > long name will see a warning message, but the user will be added to > /etc/passwd file anyway. > > So nothing compiled into the code enforces an 8-character maximum > today if a system administrator chooses to use longer usernames; all > that really remains of the limit is the attractive nuisance of > LOGNAME_MAX. > > One alternative that I haven't fully explored is to (conditionally or > unconditionally) delete LOGNAME_MAX from limits.h, forcing > applications to rely on the dynamic size returned by sysconf(). We > have long recognized an exception to the backwards compatibility > requirements when an interface contains an inherent risk of data > corruption, and that seems to be evident here; given that an > alternative interface exists (sysconf(_SC_LOGIN_NAME_MAX)), and also > given the prevalence of other systems which don't bother to define > LOGNAME_MAX, this may well be a safer path. > > - Bill > From darrenm@opensolaris.org Fri May 21 09:08:28 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LG8RPp007640 for ; Fri, 21 May 2010 09:08:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LG8OND027697 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 11:08:27 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S00M1H263WU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 09:08:27 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00HK9261Q670@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 09:08:25 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4LG8PmX009652 for ; Fri, 21 May 2010 16:08:25 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KJiDrZ030888; Fri, 21 May 2010 16:08:21 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 257999661274458078; Fri, 21 May 2010 09:07:58 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 09:07:57 -0700 Date: Fri, 21 May 2010 17:07:54 +0100 From: Darren J Moffat Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4bf6ad8d.gfcg08pgDL8l40um%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de, carlsonj@workingcode.com Cc: PSARC-ext@sun.com Message-id: <4BF6AFDA.5070408@opensolaris.org> Organization: Oracle Solaris Security Engineering MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BF6AFF6.00C1,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> <4BF641E6.8060600@Oracle.COM> <4BF66B6A.9020107@workingcode.com> <4BF66CCD.7010804@opensolaris.org> <4BF6A480.6060008@workingcode.com> <4BF6A6F9.60007@opensolaris.org> <4BF6AB62.8040507@workingcode.com> <4bf6ad8d.gfcg08pgDL8l40um%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1182 On 21/05/2010 16:58, Joerg.Schilling@fokus.fraunhofer.de wrote: >> LOGNAME_MAX is documented as a public committed interface in >> limits.h(3HEAD). How do you deal with that? > > LOGNAME_MAX is not part of the standard. > > As Solaris removed "utmp" and "wtmp" a long time ago, I would guess that > it can be seen as historical entry that may stay at it's current value > as long as the standard name LOGIN_NAME_MAX is OK. I'm not proposing it stays at its current value though. The proposal is that it be increased. I don't see anywhere on limits.h(3HEAD) that says we won't change the value of LOGNAME_MAX it is the name that would be the Committed interface not the value of it. LOGNAME_MAX is listed in the "Other Invariant Values" section. They way I understand this is that it won't vary between compile time and run time on this operating system, not that it won't ever change between releases. Code compiled on Solaris 10 or earlier or existing builds of OpenSolaris won't magically be broken they will behave the same way the always do. Code compiled on future releases/builds isn't guaranteed to work on older releases/builds anyway. -- Darren J Moffat From carlsonj@workingcode.com Fri May 21 09:24:40 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LGOe06008100 for ; Fri, 21 May 2010 09:24:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LGOc6G026235 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 09:24:39 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0053L2X2IH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:24:38 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00KRF2X25I60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:24:38 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LGHuYY000479 for ; Fri, 21 May 2010 16:24:38 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-965515 for PSARC-ext@sun.com; Fri, 21 May 2010 16:24:38 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-221079313 for PSARC-ext@sun.com; Fri, 21 May 2010 16:24:37 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-17175527 for PSARC-ext@sun.com; Fri, 21 May 2010 16:24:35 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4LGNcld006557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 12:23:43 -0400 (EDT) Date: Fri, 21 May 2010 12:23:37 -0400 From: James Carlson Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF6AFDA.5070408@opensolaris.org> To: Darren J Moffat Cc: Joerg.Schilling@fokus.fraunhofer.de, PSARC-ext@sun.com Message-id: <4BF6B389.7070007@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-z.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.077sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> <4BF641E6.8060600@Oracle.COM> <4BF66B6A.9020107@workingcode.com> <4BF66CCD.7010804@opensolaris.org> <4BF6A480.6060008@workingcode.com> <4BF6A6F9.60007@opensolaris.org> <4BF6AB62.8040507@workingcode.com> <4bf6ad8d.gfcg08pgDL8l40um%Joerg.Schilling@fokus.fraunhofer.de> <4BF6AFDA.5070408@opensolaris.org> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2533 Darren J Moffat wrote: > On 21/05/2010 16:58, Joerg.Schilling@fokus.fraunhofer.de wrote: >>> LOGNAME_MAX is documented as a public committed interface in >>> limits.h(3HEAD). How do you deal with that? >> >> LOGNAME_MAX is not part of the standard. >> >> As Solaris removed "utmp" and "wtmp" a long time ago, I would guess that >> it can be seen as historical entry that may stay at it's current value >> as long as the standard name LOGIN_NAME_MAX is OK. > > I'm not proposing it stays at its current value though. The proposal is > that it be increased. > > I don't see anywhere on limits.h(3HEAD) that says we won't change the > value of LOGNAME_MAX it is the name that would be the Committed > interface not the value of it. Unfortunately, that's not how #defines actually work. The value itself gets baked into the applications that are compiled with it. It can't actually change afterwards. That's why we have "_O" ioctls all over the system, and why fileno() took so long to get rid of. #defines are like C++ inlines; an ABI nightmare. And it's why the ARC has _LONG_ taken the position that #defines used for public symbols are simply not changeable, particularly those with the intended purpose of defining storage allocation. > LOGNAME_MAX is listed in the "Other Invariant Values" section. They way > I understand this is that it won't vary between compile time and run > time on this operating system, not that it won't ever change between > releases. What happens if I build a library on OpenSolaris build 134 that (unfortunately) uses this public symbol in a crucial way, and then I upgrade to build 145 (or whatever has your change), and then build an application using the library? Doesn't the invariance of this constant seem a bit impermanent? I agree that no application "should" do this. No problem there. But it's still a public symbol and this is an incompatible change that's not accounted for in the release binding that's asserted. If the rules no longer mean anything, that's probably fine. It might be good, though, to have new ones, or at least toss out the existing ones rather than fast-tracking exceptions. > Code compiled on Solaris 10 or earlier or existing builds of OpenSolaris > won't magically be broken they will behave the same way the always do. Unless you link to it. > Code compiled on future releases/builds isn't guaranteed to work on > older releases/builds anyway. Wasn't expecting it. -- James Carlson 42.703N 71.076W From Nicolas.Williams@oracle.com Fri May 21 09:27:46 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LGRkNo008127 for ; Fri, 21 May 2010 09:27:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LGRi9j002265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 09:27:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0050X32ATF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:27:46 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00K023285X70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:27:44 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4LGRhDl028447 for ; Fri, 21 May 2010 16:27:44 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LAKKBq017564; Fri, 21 May 2010 16:27:39 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 258055721274459219; Fri, 21 May 2010 09:26:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 09:26:58 -0700 Date: Fri, 21 May 2010 11:26:54 -0500 From: Nicolas Williams Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF6AFDA.5070408@opensolaris.org> To: Darren J Moffat Cc: Joerg.Schilling@fokus.fraunhofer.de, carlsonj@workingcode.com, PSARC-ext@sun.com Message-id: <20100521162653.GA9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BF6B47C.01DF:SCFMA4539814,ss=1,fgs=0 References: <20100520200101.GR9605@oracle.com> <45590DFB-A0F7-4CF1-B0C2-B0B1A5327F74@sonic.net> <4BF641E6.8060600@Oracle.COM> <4BF66B6A.9020107@workingcode.com> <4BF66CCD.7010804@opensolaris.org> <4BF6A480.6060008@workingcode.com> <4BF6A6F9.60007@opensolaris.org> <4BF6AB62.8040507@workingcode.com> <4bf6ad8d.gfcg08pgDL8l40um%Joerg.Schilling@fokus.fraunhofer.de> <4BF6AFDA.5070408@opensolaris.org> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1112 On Fri, May 21, 2010 at 05:07:54PM +0100, Darren J Moffat wrote: > I don't see anywhere on limits.h(3HEAD) that says we won't change > the value of LOGNAME_MAX it is the name that would be the Committed > interface not the value of it. > > LOGNAME_MAX is listed in the "Other Invariant Values" section. They > way I understand this is that it won't vary between compile time and > run time on this operating system, not that it won't ever change > between releases. > > Code compiled on Solaris 10 or earlier or existing builds of > OpenSolaris won't magically be broken they will behave the same way > the always do. Code compiled on future releases/builds isn't > guaranteed to work on older releases/builds anyway. Customers who have old binaries that depend on LOGNAME_MAX being == 9 can simply restrict themselves to 8- byte usernames. Those binaries will have been observed to break long ago too, which means there must not be very many such apps around. Incidentally and FWIW, I don't agree that this case is not fasttrack fodder. And I agree that an opinion would do absolutely nothing. Nico -- From bart.smaalders@oracle.com Fri May 21 10:08:03 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LH82lg009131 for ; Fri, 21 May 2010 10:08:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LH81dL027788 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 12:08:02 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S009394XEOZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 11:08:02 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00K3F4XC5V90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 11:08:01 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4LH80OU391235; Fri, 21 May 2010 10:08:00 -0700 (PDT) Date: Fri, 21 May 2010 10:05:50 -0700 From: Bart Smaalders Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <4BF643A5.1020705@Oracle.COM> To: Darren J Moffat Cc: Roland Mainz , PSARC-ext@sun.com, Darren J Moffat Message-id: <4BF6BD6E.8040008@oracle.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> <4BF643A5.1020705@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1105 On 20/05/2010 18:50, Roland Mainz wrote: > tools like Solaris's tools like "useradd" always restricted this to > the ASCII character set while many sites allow (by using their own set > of tools) non-ASCII usernames (e.g. German umlauts are commonly used > on German university sites and some japanese customers have been using > Japanese characters for some time) and other operating systems even > allow a larger set of multibyte characters to be used. > IMO this case should either allow the use of multibyte characters or > expcitly refer to bytes/ASCII characters (see below). Since there is no way of storing encoding information along with the username, any attempt to use multibyte will result in display issues on multi-locale environments; whether or not this is satisfactory is up to the users in question. The OS should 8 bit clean wrt usernames just as it is for filenames; the same problems exist there. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaalders@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From alan.coopersmith@oracle.com Fri May 21 10:57:07 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LHv7pp010394 for ; Fri, 21 May 2010 10:57:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LHv7bm005299 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 10:57:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S00E0B7770W00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 11:57:07 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00KR37765QB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 11:57:06 -0600 (MDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LHv5wn009090; Fri, 21 May 2010 10:57:06 -0700 (PDT) Date: Fri, 21 May 2010 10:57:05 -0700 From: Alan Coopersmith Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF5A096.5080600@workingcode.com> To: James Carlson Cc: Nicolas Williams , PSARC-ext@sun.com, Don Cragun Message-id: <4BF6C971.8000008@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <20100520200101.GR9605@oracle.com> <4BF59EB6.9060609@oracle.com> <4BF5A096.5080600@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1086 James Carlson wrote: > Just for the sake of sanity, I'd like to see a rule limiting > system-supplied names to 8 characters, at least for a while. In the best Postelian tradition of "Be liberal in what you accept, and conservative in what you send." and in the spirit of the many other "not this case" answers in this review, how about we just record in the case log: This case modifies Solaris/OpenSolaris to accept usernames longer than 8 characters. This case does *not* modify Solaris/OpenSolaris to provide any default users with usernames longer than 8 characters, nor does it modify the (probably unwritten but long and well enforced) requirement that cases adding new users to the system provide a user name that is no more than 8 characters from the subset of ASCII documented in passwd(4). If/when a case comes to the ARC proposing a username that doesn't fit that requirement, it will be responsible for establishing new policy/precedent. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From gww@sac.sfbay.sun.com Fri May 21 11:17:27 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LIHRTq010752 for ; Fri, 21 May 2010 11:17:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LIHQOb015955 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 11:17:26 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S00F01852QN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 12:17:26 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00KRK8525QC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 12:17:26 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LIHPvh018651; Fri, 21 May 2010 11:17:25 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LIHPdX010749; Fri, 21 May 2010 11:17:25 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4LIHPv3010748; Fri, 21 May 2010 11:17:25 -0700 (PDT) Date: Fri, 21 May 2010 11:17:25 -0700 (PDT) From: Gary Winiger Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] To: alan.coopersmith@oracle.com, carlsonj@workingcode.com Cc: Nicolas.Williams@oracle.com, PSARC-ext@sun.com, dcragun@sonic.net Message-id: <201005211817.o4LIHPv3010748@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1372 > From alan.coopersmith@oracle.com Fri May 21 10:57:07 2010 > Date: Fri, 21 May 2010 10:57:05 -0700 > From: Alan Coopersmith > Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] > To: James Carlson > Cc: Nicolas Williams , PSARC-ext@sun.com, > Don Cragun > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.4.1.325704 > X-Enigmail-Version: 0.95.1 > User-Agent: Thunderbird 2.0.0.23 (X11/20090926) > > James Carlson wrote: > > Just for the sake of sanity, I'd like to see a rule limiting > > system-supplied names to 8 characters, at least for a while. > > In the best Postelian tradition of "Be liberal in what you accept, and > conservative in what you send." and in the spirit of the many other > "not this case" answers in this review, how about we just record in the > case log: > > This case modifies Solaris/OpenSolaris to accept usernames longer > than 8 characters. Just catching up. Exactly, this case enables administrators to create usernames up to sizeof (utmpx.ut_user). It does nothing to require administrators to create such names. Indeed legacy names (except sommerfeld ;-) are already likely to be no more than 8 charactrers (bytes). It makes no change to the existing system defined names. Gary.. From dcragun@sonic.net Fri May 21 14:00:38 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LL0c6H014451 for ; Fri, 21 May 2010 14:00:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LL0b7X016655 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 15:00:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0062XFP18200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 14:00:37 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S009L6FP0IK50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 14:00:36 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LKtw0j018695 for ; Fri, 21 May 2010 21:00:36 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-977771 for PSARC-ext@sun.com; Fri, 21 May 2010 21:00:36 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-669394 for PSARC-ext@sun.com; Fri, 21 May 2010 21:00:35 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay1i.sun.com with ESMTP id BT-MMP-11409296 for PSARC-ext@sun.com; Fri, 21 May 2010 21:00:35 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4LKxvcg022029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 May 2010 13:59:57 -0700 Date: Fri, 21 May 2010 13:59:57 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: To: Darren J Moffat , opensolaris-arc-request@opensolaris.org Cc: carlsonj@workingcode.com, PSARC-ext@sun.com Message-id: <378D8CAF-F898-45FE-9FB5-E8638FAEE649@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.335sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: Status: RO Content-Length: 2923 On May 21, 2010, at 16:30:01 +0100, darrenm@opensolaris.org wrote: > On 21/05/2010 16:19, James Carlson wrote: >> The second is the standards group branding issue. The value 9 is baked >> into the UNIX98 and UNIX03 reference materials, so changing it (at least >> inside those conforming environments) means either re-doing the branding >> or ceasing to be "UNIX" in that sense. Obviously not an architectural >> issue, but something non-trivial that should be noted. > > My understanding is that this is the distinction between > _POSIX_LOGIN_NAME_MAX which this case explicitly stated stays a 9, and > LOGIN_NAME_MAX which is only required to be a minimum of > _POSIX_LOGIN_NAME_MAX. Yes, _POSIX_LOGIN_NAME_MAX must be defined and must have the value 9 on all conforming implementations. Yes, LOGIN_NAME_MAX must have a value >= _POSIX_LOGIN_NAME_MAX or be "unlimited" (signified by value -1). However, the value of LOGIN_NAME_MAX must be documented in the conformance statement questionnaire which is part of the UNIX branding package. The Oracle CSQ for Solaris X86 Platform Edition on releases 10 and on and for Solaris SPARC Platform Edition on releases 10 and on in the Mandatory Products Standards section on Internationalised System Calls and Libraries Extended V3 as documented in http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7 specifies that the minimum value of LOGIN_NAME_MAX is 9 and the maximum value of LOGIN_NAME_MAX is 9. So, making the changes proposed in this case require one of the following: 1. apply for a new brand for whatever Solaris release contains this change, or 2. stop using the UNIX trademark. > > The #define I'm changing in is neither of those it is > LOGNAME_MAX. The #define in for _POSIX_LOGIN_NAME_MAX stays > at 9. > > I could be convinced to just take LOGNAME_MAX out of scope and make it > Consolidation Private - or maybe to remove it completely. This I > believe is Bill's preference. Removing a committed interface in a minor release is not appropriate. > >> I was hoping to convince you that, although there's nothing wrong with >> the proposal, and that it's technically simple to accomplish, the nature >> of it places it outside the bounds of a traditional fast-track, and that >> allowing "mission creep" on fast-tracks is a bad thing overall for >> OpenSolaris. > > What you aren't convincing me of is what value an ARC opinion will have > in this particular case. > > I see no value in an ARC opinion here since there has been no suggested > Advice to any other party. As noted above, this is not an ARC issue, but it is a business issue. In my not so humble opinion, this requires some party or parties outside of the ARC within Oracle to be notified of the impact of this change. Therefore, I believe an opintion needs to be written. - Don > > -- > Darren J Moffat From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri May 21 14:55:58 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LLtvLu015416 for ; Fri, 21 May 2010 14:55:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LLtubO042831 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 15:55:57 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S00H09I99WJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 14:55:57 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00F4WI98LW30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 14:55:56 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4LLtreT019928 for ; Fri, 21 May 2010 21:55:56 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-979817 for PSARC-ext@sun.com; Fri, 21 May 2010 21:55:53 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-71161 for PSARC-ext@sun.com; Fri, 21 May 2010 21:55:52 +0000 (Z) Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay1i.sun.com with ESMTP id BT-MMP-17835631 for PSARC-ext@sun.com; Fri, 21 May 2010 21:55:51 +0000 (Z) Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 594585EC2B2; Fri, 21 May 2010 23:55:50 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 6FB455EC27D; Fri, 21 May 2010 23:55:48 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o4LLtmOg026313; Fri, 21 May 2010 23:55:48 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 23:55:48 +0200 Date: Fri, 21 May 2010 23:55:44 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <378D8CAF-F898-45FE-9FB5-E8638FAEE649@sonic.net> Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: opensolaris-arc-request@opensolaris.org, dcragun@sonic.net, darrenm@opensolaris.org Cc: PSARC-ext@sun.com Message-id: <4bf70160.cCsfq1ey8hxndQ+v%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.130sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <378D8CAF-F898-45FE-9FB5-E8638FAEE649@sonic.net> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 21 May 2010 21:55:48.0060 (UTC) FILETIME=[5EF8F1C0:01CAF930] Status: RO Content-Length: 942 Don Cragun wrote: > http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7 > specifies that the minimum value of LOGIN_NAME_MAX is 9 and the > maximum value of LOGIN_NAME_MAX is 9. So, making the changes proposed > in this case require one of the following: > 1. apply for a new brand for whatever Solaris release contains > this change, or > 2. stop using the UNIX trademark. Are you sure that not a single of the other changes (e.g. replacing commands in /usr/bin or /usr/xpg*/bin) caused the need for a re-evaluation? IIRC, the validation was done for Solaris 10 and not for ON. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From dcragun@sonic.net Fri May 21 15:12:01 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LMC0JE015558 for ; Fri, 21 May 2010 15:12:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LMC02B050249 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 16:12:00 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0020FJ00S000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 15:12:00 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S0094UIZZIKA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 15:12:00 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LM2Vlm004345 for ; Fri, 21 May 2010 22:11:59 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-1214423 for PSARC-ext@sun.com; Fri, 21 May 2010 22:11:59 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-166022418 for PSARC-ext@sun.com; Fri, 21 May 2010 22:11:59 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-14072890 for PSARC-ext@sun.com; Fri, 21 May 2010 22:11:58 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o4LMBDvA025965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 May 2010 15:11:14 -0700 Date: Fri, 21 May 2010 15:11:13 -0700 From: Don Cragun Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4bf70160.cCsfq1ey8hxndQ+v%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <91FC9C5B-779D-4A9C-ABE9-01BF4B75FAE4@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: text/plain; charset=iso-8859-1 X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.229sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <378D8CAF-F898-45FE-9FB5-E8638FAEE649@sonic.net> <4bf70160.cCsfq1ey8hxndQ+v%Joerg.Schilling@fokus.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o4LMC0JE015558 Status: RO Content-Length: 1584 On May 21, 2010, at 2:55 PM, Joerg Schilling wrote: > Don Cragun wrote: > >> http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7 >> specifies that the minimum value of LOGIN_NAME_MAX is 9 and the >> maximum value of LOGIN_NAME_MAX is 9. So, making the changes proposed >> in this case require one of the following: >> 1. apply for a new brand for whatever Solaris release contains >> this change, or >> 2. stop using the UNIX trademark. > > Are you sure that not a single of the other changes (e.g. replacing commands in > /usr/bin or /usr/xpg*/bin) caused the need for a re-evaluation? When I worked at Sun, part of my job was keeping track of this issue. Since I no longer see all of the bug reports filed against standards issues, utilities, libraries, the kernel, etc.; I can not be sure that other changes I haven's seen do not affect branding. I have commented on other cases about plans that appear to affect conformance. I have not noticed anything coming before PSARC modifying utilities covered by POSIX/SUS that should affect the CSQs or other branding materials. I'm following PSARC on my own dime, hopefully providing a useful service, but I make no claim that I am keeping Solaris clean for branding. If Oracle wants me to do that, they need to rehire me and put that in my job description. > > IIRC, the validation was done for Solaris 10 and not for ON. Correct. The validation includes some, but not all, of ON and includes bits and pieces from many other consolidations. - Don > > Jörg From scott.rotondo@oracle.com Wed May 26 14:27:13 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4QLRDJL010083 for ; Wed, 26 May 2010 14:27:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4QLRDJq026951 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 26 May 2010 14:27:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3100501Q9DAQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 May 2010 14:27:13 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3100JF5Q9CVI60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 May 2010 14:27:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4QLRCDn020492 for ; Wed, 26 May 2010 21:27:12 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4QHHgVO018430 for ; Wed, 26 May 2010 21:27:10 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 271538821274909173; Wed, 26 May 2010 14:26:13 -0700 Received: from [129.146.108.62] (/129.146.108.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 May 2010 14:26:13 -0700 Date: Wed, 26 May 2010 14:26:19 -0700 From: Scott Rotondo Subject: Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010] In-reply-to: <4BF6A738.4070802@workingcode.com> To: PSARC-ext@sun.com Message-id: <4BFD91FB.9080706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BFD922F.0138:SCFMA4539814,ss=1,fgs=0 References: <0292A58E-182E-464B-BD8E-CCFFB3C3B79B@sonic.net> <4BF5A899.2020905@oracle.com> <523E08BA-0507-44C3-94CD-FBA68C6841BA@sonic.net> <4BF66C83.8040902@workingcode.com> <4BF67F3E.4020009@Oracle.COM> <4BF6A738.4070802@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2155 On 05/21/10 08:31 AM, James Carlson wrote: > Darren J Moffat wrote: >> On 21/05/2010 12:20, James Carlson wrote: >>> On 05/20/10 22:51, Don Cragun wrote: >>>> Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a >>>> "Conforming POSIX Application Using Extensions" is free to use >>>> LOGNAME_MAX as defined in as long as it documents that it >>>> uses this macro (and __EXTENSIONS__ as defined on the standards(5) >>>> man page). You may wish that applications wouldn't do that, but >>>> according to the standards, using documented features of an >>>> implementation is not a bug; it just makes the program source less >>>> portable. >>> >>> That only counts when in such an environment, though. A reasonable >>> solution (borrowing from Bill's suggestion) would be to have LOGNAME_MAX >>> defined as 9 when in a conforming environment, and intentionally >>> undefined elsewhere. >> >> No I don't think that is reasonable, because it will only cause to >> create applications that can only deal with shorter usernames which will >> be different to the rest of the system. For the #define it will only >> come into play if the application is recompiled on a release with this >> change. Ultimately this just causes problems for users and admins. > > It preserves the existing branding, allows "normal" applications to be > improved, and permits those who feel they need strict conformance to get > it. You can't have everything. Assuming there is a standards-conformance issue that requires the smaller value in some circumstances [1], I don't see the downside in providing the old #define for compilations that specifically request the conforming environment. It still lets us take advantage of longer usernames for everything in Solaris and most real-world programs without making the conformance/branding situation any more difficult than it already is. Scott [1] I haven't studied that issue carefully, but I'm willing to accept that such a situation exists. -- Scott Rotondo Senior Principal Engineer, Solaris Core OS Engineering President, Trusted Computing Group Phone: +1 650 786 6309 (Internal x86309) From Joerg.Barfurth@sun.com Thu May 27 03:21:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4RALMaW012295 for ; Thu, 27 May 2010 03:21:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4RALLPK004229 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 May 2010 05:21:21 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3200009Q3LPH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 03:21:21 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L32008VGQ3K4QD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 03:21:21 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4RALKne001313 for ; Thu, 27 May 2010 10:21:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L3200J00Q08ZF00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 11:21:12 +0100 (BST) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L3200JL0Q3CKOG0@fe-emea-13.sun.com>; Thu, 27 May 2010 11:21:12 +0100 (BST) Date: Thu, 27 May 2010 12:21:12 +0200 From: Joerg Barfurth Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> Sender: Joerg.Barfurth@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4BFE4798.7090503@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 3490 Coming late to the discussion. Darren J Moffat schrieb: > Solaris currently documents a maximum username length of 8 characters > in passwd(4). > > Other Operating Systems don't have such a small limit. In fact Solaris > mostly works and has for quite some time with usernames upto 32 > characters. > > The 8 character limit is manifest in three places > 1) the LOGNAME_MAX constant in (8) > 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9) > This symbol is deprecated for XPG6 / SUSv3 onwards. > 3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9) > > The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns > the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX > is the minumum acceptable value. That implies that they need not be > the same. > > This case changes so that we have: > 1) the LOGNAME_MAX constant in (32) As others have commented that breaks ABI for any libraries that use character arrays of this size in their interfaces. That makes such changes risky for customers, in particular ISVs. > 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33) > This symbol is deprecated for XPG6 / SUSv3 onwards. I don't see the point of changing this value. Its only real use is the length of a character array to pass to cuserid(3C). You cannot change cuserid(3C) to use more than 9 bytes of a caller-provided buffer, as existing binaries have the old value of L_cuserid compiled in. Changing that would require a major release that makes sure all uses of this API are recompiled. > 3) getconf _POSIX_LOGIN_NAME_MAX (9) > 4) getconf LOGIN_NAME_MAX (33) > Unfortunately the getlogin(3C) man page documents for getlogin_r that 'The name buffer must be at least _POSIX_LOGIN_NAME_MAX bytes in size', suggesting that that size would be sufficient to hold any result. Even if that documentation is changed to suggest use of LOGIN_NAME_MAX, existing code following that recommendation may break when encountering long user names. At least the getlogin_r(3C) call can signal the error properly (as opposed to cuserid(3C)). > Ideally code should use sysconf to lookup LOGIN_NAME_MAX but there is > also a lot of exsting that derives the size using something like this: > (sizeof (((struct utmpx *)0)->ut_name)) > > > The method for fixing utilities that are currently restricted to 8 > character usernames is outside the scope of the ARC case and is really > an issue for the codereviewers and CRT advocates. Though it is highly > recommended that "32" not be hardcoded into a local constant but > instead either LOGNAME_MAX from be used or if possible > sysconf(3C), the method of using the ut_name field is acceptable > particularly if it means minimal code change. > Of course the real bulk of code affected and left in need of fixing is customer and ISV code. Changing fixed length defines creates the risk of breaking ISV ABI and creating buffer overrun bugs in code that is correct today. Changing getconf values is much less harmful, as code that dynamically queries such values should already be prepared to use the dynamic values. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://blogs.sun.com/joergb/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/vdi/ From alan.coopersmith@oracle.com Thu May 27 06:26:09 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4RDQ91q014928 for ; Thu, 27 May 2010 06:26:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4RDQ4iR000890 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 May 2010 06:26:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3200M4HYNLSD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 06:26:09 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3200734YNJO550@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 06:26:08 -0700 (PDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4RDQ6d5008412; Thu, 27 May 2010 06:26:06 -0700 (PDT) Date: Thu, 27 May 2010 06:26:06 -0700 From: Alan Coopersmith Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <4BFE4798.7090503@sun.com> To: Joerg Barfurth Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4BFE72EE.3090406@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> <4BFE4798.7090503@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 455 Joerg Barfurth wrote: >> This case changes so that we have: >> 1) the LOGNAME_MAX constant in (32) > > As others have commented that breaks ABI for any libraries that use > character arrays of this size in their interfaces. Do you know of any libraries actually designed that poorly or is this a purely theoretical risk? -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From Darren.Moffat@oracle.com Thu May 27 06:33:11 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4RDXB0L015036 for ; Thu, 27 May 2010 06:33:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4RDXAOR015173 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 May 2010 07:33:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L320010PYZA2O00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 06:33:10 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L32007GBYZ8O270@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 06:33:09 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4RDX8iZ026692 for ; Thu, 27 May 2010 13:33:08 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RD7ZVD016797 for ; Thu, 27 May 2010 13:33:07 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 273564931274967087; Thu, 27 May 2010 06:31:27 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 06:31:27 -0700 Date: Thu, 27 May 2010 14:31:25 +0100 From: Darren J Moffat Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <4BFE72EE.3090406@oracle.com> To: PSARC-ext@sun.com Message-id: <4BFE742D.8010409@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BFE7493.015F:SCFMA4539814,ss=1,fgs=0 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> <4BFE4798.7090503@sun.com> <4BFE72EE.3090406@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 222 I'm putting this case into waiting need opinion, once I've written a draft opinion I will call for a PSARC members vote. If you have explicit text you would like in the opinion please sent it to me. -- Darren J Moffat From Joerg.Barfurth@sun.com Thu May 27 07:26:09 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4REQ8kM017468 for ; Thu, 27 May 2010 07:26:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4REQ7kS008865 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 May 2010 09:26:08 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3300C4F1FJSX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 07:26:07 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L33007F01FFO2E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 07:26:04 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4REQ3h3000084 for ; Thu, 27 May 2010 14:26:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L330080016YIK00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 May 2010 15:25:57 +0100 (BST) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L33006691EV1820@fe-emea-09.sun.com>; Thu, 27 May 2010 15:25:43 +0100 (BST) Date: Thu, 27 May 2010 16:25:42 +0200 From: Joerg Barfurth Subject: Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010] In-reply-to: <4BFE72EE.3090406@oracle.com> Sender: Joerg.Barfurth@sun.com To: Alan Coopersmith Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4BFE80E6.70806@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <201005201601.o4KG1wsY023101@sac.sfbay.sun.com> <4BFE4798.7090503@sun.com> <4BFE72EE.3090406@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 2242 Alan Coopersmith schrieb: > Joerg Barfurth wrote: >>> This case changes so that we have: >>> 1) the LOGNAME_MAX constant in (32) >> As others have commented that breaks ABI for any libraries that use >> character arrays of this size in their interfaces. > > Do you know of any libraries actually designed that poorly or is this > a purely theoretical risk? > It is theoretical, but with some foundation in past experience. I have certainly seen quite a bit of code use defined constants from limits.h (or other system headers) to define structure fields. I recall cases using HOST_NAME_MAX, NAME_MAX, PATH_MAX and others. I have witnessed cases where developers looked around hard to find a defined constant in a system header to avoid the memory management hassles of using dynamic values. So it seems plausible to use LOGNAME_MAX for a structure field to hold a user name. And if that structure needs to be passed between dynamically linked objects it becomes part of the mutual ABI. We just can't know that no library designer has done that. And I've seen programming shops where that would have been considered good design (contrasted to using a magic numeric constant that reflects the mistaken belief of a single developer). AFAICT binary compatibility promises aren't void for 'poor design' as long as it plays within the rules of using Committed interfaces. And I have seen too many cases of 'this is incompatible, but only if someone has done something stupid' changes in OS, compiler or library releases break real, existing code. IMHO a compile-time failure that uncovers such things would be vastly preferable to a possible buffer overrun. So I'd prefer having it removed over having the value changed. If you leave a defined LOGNAME_MAX constant in a system header it is an invitation for developers to use it to define fixed-size fields which may easily wind up being part of some ABI. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://blogs.sun.com/joergb/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/vdi/