From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH] tools: make flask utils build unconditional Date: Tue, 5 Jan 2016 16:42:13 +0000 Message-ID: <20160105164213.GE27789@citrix.com> References: <1450759603-24249-1-git-send-email-cardoe@cardoe.com> <20160104122805.GG9423@citrix.com> <568A7E3F.9020108@cardoe.com> <20160104142638.GA12639@citrix.com> <1452004651.13361.289.camel@citrix.com> <1452008181.13361.328.camel@citrix.com> <20160105161328.GD27789@citrix.com> <1452011059.13361.363.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1452011059.13361.363.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Stefano Stabellini , Ian Jackson , Doug Goldstein , xen-devel@lists.xen.org, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On Tue, Jan 05, 2016 at 04:24:19PM +0000, Ian Campbell wrote: > On Tue, 2016-01-05 at 16:13 +0000, Wei Liu wrote: > > On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote: > > > On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote: > > > > = > > > > which on the basis of this discussion I wasn't expecting. I didn't > > > > see this > > > > new file on i686 or ARM*. > > > > = > > > > My baseline is from the last time I committed, which would be last > > > > year, so > > > > maybe something other than my current batch of patches has caused > > > > this. > > > > = > > > > I'm going to drop this one for now and (hopefully) get the rest of > > > > the > > > > batch squared away. Afterwards I'll take another look (with a new > > > > baseline > > > > filelist), but if someone can explain it in the meantime that would > > > > be > > > > super. > > > = > > > So with a fresh basline I still see: > > > = > > > --- ../FILE_LIST.BASE.staging.x86_64=A0=A0=A0=A02016-01-05 14:50:32.0= 00000000 > > > +0000 > > > +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000 > > > @@ -6,6 +6,7 @@ > > > =A0dist/install/boot/xen-4.7-unstable.gz > > > =A0dist/install/boot/xen-4.gz > > > =A0dist/install/boot/xen.gz > > > +dist/install/boot/xenpolicy-4.7-unstable > > > =A0dist/install/etc > > > =A0dist/install/etc/bash_completion.d > > > =A0dist/install/etc/bash_completion.d/xl.sh > > > @@ -386,6 +387,12 @@ > > > =A0dist/install/usr/local/lib/xen/libexec > > > =A0dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper > > > =A0dist/install/usr/local/sbin > > > +dist/install/usr/local/sbin/flask-get-bool > > > +dist/install/usr/local/sbin/flask-getenforce > > > +dist/install/usr/local/sbin/flask-label-pci > > > +dist/install/usr/local/sbin/flask-loadpolicy > > > +dist/install/usr/local/sbin/flask-set-bool > > > +dist/install/usr/local/sbin/flask-setenforce > > > =A0dist/install/usr/local/sbin/gdbsx > > > =A0dist/install/usr/local/sbin/gtracestat > > > =A0dist/install/usr/local/sbin/gtraceview > > > *** FILES DIFFER *** > > > = > > > On i686 and ARM* I only see the (expected) second hunk. > > > = > > > I think the i686 case is explainable by the lack of a hypervisor build > > > there, but I'm unsure why ARM* and x86_64 should differ in this regar= d. > > > = > > > config/Tools.mk is y only on x86_64, not on the others, which obvious= ly > > > explains things, but the question is why only on x86_64 (I presume th= is > > > has > > > always been the case and it was previously masked, but I've not > > > checked). > > > = > > > Ah, OK, I misread > > > = > > > AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation]) > > > = > > > as being default disable, actually the default is "enabled iff > > > checkpolicy > > > is installed" and it happens to be that it is only installed in my > > > x86_64 > > > build env. > > > = > > > So, in the end I think Wei was correct and this change will now, in > > > some > > > circumstances, end up installing a /boot/xenpolicy-*. > > > = > > = > > I don't think it is related to this patch. I see an xenpoilcy file > > without this patch applied. > = > With XSM disabled? > = > > As you said it only depends on availability > > of checkpolicy (part of generic SELinux utils, not the ones we build). > = > But then why does this file only show up for me with this patch applied? > = > You initially objected to this patch because you thought it would add this > file, but it seems like you have always had it. Is the answer just that y= ou > only just found that you always had it? > = Hmm... After I make distclean, things changed. So to be clear: without this patch applied, I don't have xenpolicy file even if checkpolicy is available. This patch does alter the behaviour somehow. I'm in the middle of rebasing one patch series, so I haven't looked into all the details. > > = > > That said, let me try to answer the following question. > > = > > > So the question is do we mind that? > > > = > > = > > We might or might not. See below. > > = > > I once submitted a patch to grub that look into /boot and generate XSM > > entries if there is policy file. The patch is not yet merged though. > > = > > Since there is no way at the moment to tell if xen.gz has flask enabled, > > my not yet upstreamed patch only matches the version number of xen.gz a= nd > > xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will > > make grub generate an XSM entry nonetheless, which makes no sense. > = > Indeed. > = > > Of course all the above is based on the theory that my grub patch is > > going to be upstreamed. > > = > > Things have changed since I first submitted that patch. Doug's Kconfig > > work is good. With .config installed in suitable location we can make > > grub grep for flask information in config, hence avoiding generating > > wrong entries.=A0=A0I think this is better solution as we don't need to= use > > version number to match xen.gz and xenpolicy. If we go down this route > > we don't mind having random xenpolicy lying around in /boot. > = > > We just need to reach an agreement on how to proceed. I would vote for > > the second solution. > = > Which is what? This patch as is? (and what is the first proposition?) > = That was referring to grub generating XSM entries. First solution is my not yet upstream patch; second is to make gurb grep .config for flask information. Wei. > Ian.