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 A69AC65E87 for ; Mon, 9 Jun 2014 14:47:24 +0000 (UTC) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.5/8.14.5) with ESMTP id s59ElGFM029599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jun 2014 07:47:16 -0700 (PDT) Received: from Marks-MacBook-Pro.local (172.25.36.228) by ALA-HCB.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.174.1; Mon, 9 Jun 2014 07:47:16 -0700 Message-ID: <5395C8F2.7040600@windriver.com> Date: Mon, 9 Jun 2014 09:47:14 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Peter Kjellerstedt , "OE Core (openembedded-core@lists.openembedded.org)" References: In-Reply-To: Subject: Re: Using users/groups from another recipe than the one creating them 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: Mon, 09 Jun 2014 14:47:29 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 6/9/14, 8:39 AM, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: openembedded-core-bounces@lists.openembedded.org >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of >> Peter Kjellerstedt >> Sent: den 23 maj 2014 12:38 >> To: OE Core (openembedded-core@lists.openembedded.org) >> Subject: Re: [OE-core] Using users/groups from another recipe than the >> one creating them >> >>> -----Original Message----- >>> From: openembedded-core-bounces@lists.openembedded.org >>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf >>> Of Peter Kjellerstedt >>> Sent: den 19 maj 2014 10:15 >>> To: OE Core (openembedded-core@lists.openembedded.org) >>> Subject: [OE-core] Using users/groups from another recipe than the >>> one creating them >>> >>> Which assumption is correct: "a recipe A that depends on another >>> recipe B can use users/groups that B creates" or "all recipes must >>> create the users/groups they require themselves"? >>> >>> The problem for us is that we have a lot of recipes that create >>> users and groups, and subsequently a number of other related recipes >>> that need to use those users and groups. >>> >>> If the first assumption is correct then the useradd.bbclass needs to >>> be corrected so that it adds a dependency from do_install to >>> base-passwd:do_populate_sysroot and >>> base-passwd:do_populate_sysroot_setscene, because if either of those >>> tasks execute they will overwrite /etc/passwd and /etc/group, >>> effectively removing any users/groups that were created earlier... >>> >>> On the other hand, if it is the second assumption that is correct, >>> then there should be QA tests in place to make sure all recipes >>> create the users/groups they use. >>> >>> //Peter >> >> *ping* >> >> Doesn't anyone know how users and groups are supposed to work? >> >> //Peter > > *ping again* I never saw the original emails, either of them. > Well, this is somewhat discouraging. Three weeks and not a single > response. Are we really the only ones that care about users and > groups and how they are created? Doesn't anyone know which of my > two assumptions above are correct? > > Personally I would prefer that all recipes create the users and > groups they require themselves as this keeps them more self > contained. I have no idea how to write a QA test to verify this, > but I assume it should be possible... The rule is: There is a limited number of base users and groups, if your package uses a user/group in that base set nothing else is needed. If your package needs an additional user/group, then it must either: *) Add the user/group itself. Multiple packages are allowed to add the same users/groups, with the understanding that the options -must- be identical! *) Must -require- (not recommend) a package that adds the group that they require. It's a good idea in the recipe to comment that the 'require' adds the user/group as well. This is pretty common where a single recipe provides multiple packages. If a common package creates the user/group, then all of the other packages [that need that user/group] should then require the common package. As far as the QA resources go. There are actually two sides to the QA. The first is in the do_install step, if the users/groups are being used there -- and don't exist -- a failure should be generated. That exists just by the nature of the system build processes. The second is that once a package has been generated (the package directory that is), it should be verified that all files are owned by in the base set of users/groups, the user/group has been added, or a dependency on the package that added them exist. This is difficult to do though. There is currently no tracking mechanism in the system to say which recipes added which users/groups to the system. A mechanism similar to the sysroot file population would be required to capture the user and group changes and by which package(s). This of course would also have to work with the sstate-cache mechanism. The first step in implementing this would be to capture the user/group changes and record them in a database. (again, I think similar to the populate sysroot file). Then during the QA process, you can iterate over the files and find out where each user/group in use comes from. If the provider is not in the 'required' set of packages generate a QA -warning- (since this is new and unproven code).. We can upgrade it to an error once it's stable. --Mark > //Peter >