From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] base-passwd: disable problematic login.defs options
Date: Sun, 19 Jun 2011 20:33:42 -0700 [thread overview]
Message-ID: <4DFEBF96.9030806@intel.com> (raw)
In-Reply-To: <BANLkTinnb_w2PNoADc3jgqpxeLcyG=z6YA@mail.gmail.com>
On 06/19/2011 07:41 PM, Khem Raj wrote:
> On Sun, Jun 19, 2011 at 7:13 PM, Mark Hatle<mark.hatle@windriver.com> wrote:
>> On 6/17/11 1:10 PM, Scott Garman wrote:
>>> On 06/17/2011 10:22 AM, Otavio Salvador wrote:
>>>> On Fri, Jun 17, 2011 at 17:19, Scott Garman<scott.a.garman@intel.com> wrote:
>>>>> Sorry, I forgot to mention that shadow-utils-native is what is used to
>>>>> modify the passwd/group files in the target sysroot. It seems that having a
>>>>> -native recipe install files into a target sysroot would be worse than
>>>>> including an optional file with base-passwd that may or may not be used in
>>>>> target systems.
>>>>
>>>> Why not make an shadow-target package with this?
>>>
>>> To just install a login.defs file? I'm open to it if a few more people
>>> think this is a better idea.
>>
>> The file is needed in order for the utilities that add, remove and modify
>> users/groups to function properly. The full version from shadow utils is used
>> so we are sure we can dead with both shadow-less and shadowed filesystem images.
>> (It's also more full featured then busybox, yet busybox is still compatible
>> with it.)
>>
> Will shadow be able to override this file ?
> one thing I see is that it wont get any updates that shadow might
> do to this file in future.
Now that I think of it, the reason Koen ran into the error messages was
that the login.defs I shipped with base-passwd had various variables
uncommented that the shadow recipe comments out (there's a sed script
included with shadow which does this). Which means that his image, which
had shadow installed, was *not* overriding the login.defs from base-passwd.
I'm now convinced that creating a shadow-cross package which just ships
a login.defs file is the right thing to do, and to remove it from
base-passwd. Thanks everyone for the feedback thus far.
I will be away at a conference for most of this coming week, but will
try to squeeze this in on Monday.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
next prev parent reply other threads:[~2011-06-20 3:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 18:49 [PATCH 0/1] Fix for runtime errors due to login.defs Scott Garman
2011-06-16 18:50 ` [PATCH 1/1] base-passwd: disable problematic login.defs options Scott Garman
2011-06-16 23:54 ` Khem Raj
2011-06-17 16:34 ` Scott Garman
2011-06-17 16:43 ` Khem Raj
2011-06-17 17:19 ` Scott Garman
2011-06-17 17:22 ` Otavio Salvador
2011-06-17 18:10 ` Scott Garman
2011-06-20 2:13 ` Mark Hatle
2011-06-20 2:41 ` Khem Raj
2011-06-20 3:33 ` Scott Garman [this message]
2011-06-17 10:11 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DFEBF96.9030806@intel.com \
--to=scott.a.garman@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.