From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id 4916773D46 for ; Fri, 6 Nov 2015 20:14:27 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.15.2/8.15.1) with ESMTPS id tA6KEN1N020473 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Nov 2015 12:14:23 -0800 (PST) Received: from Marks-MacBook-Pro.local (172.25.36.227) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.248.2; Fri, 6 Nov 2015 12:14:23 -0800 To: Peter Kjellerstedt References: <5639522B.5050604@windriver.com> From: Mark Hatle Organization: Wind River Systems Message-ID: <563D0A1E.9060601@windriver.com> Date: Fri, 6 Nov 2015 14:14:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Cc: "openembedded-core@lists.openembedded.org" Subject: Re: [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group files before parsing X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 20:14:28 -0000 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit On 11/6/15 2:09 PM, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: Mark Hatle [mailto:mark.hatle@windriver.com] >> Sent: den 4 november 2015 01:33 >> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org >> Subject: Re: [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group >> files before parsing >> >> On 11/3/15 6:06 PM, Peter Kjellerstedt wrote: >>> Read and merge the passwd/group files before parsing the user and >>> group definitions. This means they will only be read once per >>> recipe. This solves a problem where if a user was definied in multiple >>> files, it could generate group definitions for groups that should not >>> be created. E.g., if the first passwd file read defines a user as: >>> >>> foobar::1234:::: >>> >>> and the second passwd file defines it as: >>> >>> foobar:::nogroup:The foobar user:/:/bin/sh >>> >>> then a foobar group would be created even if the user will use the >>> nogroup as its primary group. >> >> One minor thing >> >>> @@ -251,7 +269,7 @@ def update_useradd_static_config(d): >>> >>> newparams.append(newparam) >>> >>> - return " ;".join(newparams).strip() >>> + return ";".join(newparams).strip() >>> >>> # Load and process the users and groups, rewriting the adduser/addgroup params >>> useradd_packages = d.getVar('USERADD_PACKAGES', True) >>> >> >> The space was required because you could generate a user/group add >> line that ended with a string. Without the space, you could end up >> merging two sets of arguments causing a failure condition. >> >> So I think that it should be retained unless there is a specific >> reason you believe it should be removed. > > I cannot see how that space can make any difference. Each set of > useradd/grouppadd options added to newparams has the user/group > name at the end of the string. And if that somehow interferes with > the semicolon, then the code in useradd.bbclass which simply does > "cut -d ';'" to split the useradd/groupadd line would break already. The contents when originally parsed my be run as arguments to a shell script or as parameters to these functions. In the shell script world not have a space can confuse the argument parsing into thinking the ; is part of the argument. You don't have that in the python world with the split behavior. > Actually, now that I think about it, I do wonder why > useradd-staticids.bbclass use this advanced variant to split the > useradd/groupadd lines: > > for param in re.split('''[ \t]*;[ \t]*(?=(?:[^'"]|'[^']*'|"[^"]*")*$)''', params): It is perfectly legal to allow a ';' in the middle of a parameter (that allows it), a parameter that is quoted. Something like: adduser -c "This user;that user;all users" -d /home/allusers alluser it's odd, but I've certainly seen people put ';' in the comment before.. and it is legal in other palces, like the home dir and such -- just not advised. > when this would do the job just as well: > > for param in params.split(';'): > > given that that is what useradd.bbclass does. It looks as if tries > to support something like --comment "something with a ; in it", but > using that would break in useradd.bbclass anyway... Then the useradd class is broken in this case. The --comment processing needs to work, it's just rarely used in the normal case, but very much used in the "lets take a previously generated passwd file and reuse it" case of the adduser-static. > //Peter >