Re: [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group files before parsing

[Mark Hatle <mark.hatle@windriver.com>]

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
>