From: Patrick Ohly <patrick.ohly@intel.com>
To: "Mark Hatle" <mark.hatle@windriver.com>,
"José Bollo" <jobol@nonadev.net>,
"wenzong fan" <wenzong.fan@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] shadow: 'useradd' copies root's extended attributes
Date: Wed, 10 Jan 2018 12:15:19 +0100 [thread overview]
Message-ID: <1515582919.6718.21.camel@intel.com> (raw)
In-Reply-To: <0f571a17-21c2-7d3d-96eb-cabf261af289@windriver.com>
On Tue, 2018-01-09 at 11:51 -0600, Mark Hatle wrote:
> On 1/4/18 4:41 AM, Patrick Ohly wrote:
> > On Thu, 2018-01-04 at 11:18 +0100, José Bollo wrote:
> > > > Do you agree to move the patch to Smack specific layer? Such
> > > > as
> > > > meta-security?
> > >
> > > I agree.
> >
> > Layers like meta-security should not modify recipes from other
> > layers,
> > at least not by default. That would violate the "Yocto Compatible
> > 2.0"
> > rules.
>
> You can modify (bbappend) to an existing recipe. You can't change
> the behavior
> (specifically the md5sum) of the function though, unless that new
> functionality
> is enabled.)
That's what I meant with "by default".
> 'smack' should be able to do the same thing, with a similar distro
> feature.
I'm not convinced that building core components differently depending
on such distro features is desirable, because it makes "smack" and
"selinux" mutually exclusive. I'd prefer a solution where support for
both can be enabled and then on the image itself the tools decide what
to do. Whether that's always possible of course is a different
question.
In this case I think it is, by adding the exception for
security.selinux. But I'll leave that up to you and Jose to decide.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2018-01-10 11:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 14:07 [PATCH] shadow: 'useradd' copies root's extended attributes jobol
2017-03-09 16:07 ` Patrick Ohly
2017-03-09 16:48 ` José Bollo
2017-03-09 17:18 ` Patrick Ohly
2017-03-15 8:04 ` José Bollo
2018-01-04 9:28 ` wenzong fan
2018-01-04 9:31 ` wenzong fan
2018-01-04 10:18 ` José Bollo
2018-01-04 10:41 ` Patrick Ohly
2018-01-04 11:39 ` wenzong fan
2018-01-04 11:50 ` Patrick Ohly
2018-01-05 1:07 ` Fan, Wenzong
2018-01-09 17:01 ` Patrick Ohly
2018-01-10 9:50 ` wenzong fan
2018-01-15 14:33 ` José Bollo
2018-01-15 16:58 ` Patrick Ohly
2018-01-16 2:53 ` wenzong fan
2018-01-09 17:51 ` Mark Hatle
2018-01-10 11:15 ` Patrick Ohly [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-03-13 9:57 jobol
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=1515582919.6718.21.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=jobol@nonadev.net \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=wenzong.fan@windriver.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox