From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH] tools: make flask utils build unconditional Date: Fri, 8 Jan 2016 12:49:07 -0600 Message-ID: <569004A3.1080705@cardoe.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> <20160105164213.GE27789@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6142498236825172790==" Return-path: In-Reply-To: <20160105164213.GE27789@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: Wei Liu , Ian Campbell Cc: Daniel De Graaf , xen-devel@lists.xen.org, Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6142498236825172790== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DT0oDWAG2IJa4mI2u1Rslr5OV6av33pVC" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DT0oDWAG2IJa4mI2u1Rslr5OV6av33pVC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/5/16 10:42 AM, Wei Liu wrote: > 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 2016-01-05 14:50:32.00000000= 0 >>>> +0000 >>>> +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000 >>>> @@ -6,6 +6,7 @@ >>>> dist/install/boot/xen-4.7-unstable.gz >>>> dist/install/boot/xen-4.gz >>>> dist/install/boot/xen.gz >>>> +dist/install/boot/xenpolicy-4.7-unstable >>>> dist/install/etc >>>> dist/install/etc/bash_completion.d >>>> dist/install/etc/bash_completion.d/xl.sh >>>> @@ -386,6 +387,12 @@ >>>> dist/install/usr/local/lib/xen/libexec >>>> dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper >>>> dist/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 >>>> dist/install/usr/local/sbin/gdbsx >>>> dist/install/usr/local/sbin/gtracestat >>>> dist/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 bui= ld >>>> there, but I'm unsure why ARM* and x86_64 should differ in this rega= rd. >>>> >>>> config/Tools.mk is y only on x86_64, not on the others, which obviou= sly >>>> explains things, but the question is why only on x86_64 (I presume t= his >>>> 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)= =2E >> >> But then why does this file only show up for me with this patch applie= d? >> >> 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 tha= t you >> only just found that you always had it? >> >=20 > Hmm... After I make distclean, things changed. >=20 > 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. >=20 > I'm in the middle of rebasing one patch series, so I haven't looked > into all the details. >=20 >>> >>> 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 XS= M >>> 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 enabl= ed, >>> my not yet upstreamed patch only matches the version number of xen.gz= and >>> 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 Kconfi= g >>> work is good. With .config installed in suitable location we can make= >>> grub grep for flask information in config, hence avoiding generating >>> wrong entries. I think this is better solution as we don't need to u= se >>> version number to match xen.gz and xenpolicy. If we go down this rout= e >>> 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 fo= r >>> the second solution. >> >> Which is what? This patch as is? (and what is the first proposition?) >> >=20 > 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. >=20 > Wei. >=20 >> Ian. Ok so I'm at a loss what steps I need to take. I've submitted patches to put the config in /boot so that this check can be made but there's a disagreement if that's even necessary or not. Do I need to supply a patch to make --disable-xsmpolicy the default so that this change doesn't generate the policy by default? The point of this patch is to compile the necessarily bits always which will help shake out bugs earlier. If we don't want the policy file to be installed then we should use the proper setting for that and not the fact that the utility isn't being compiled. --=20 Doug Goldstein --DT0oDWAG2IJa4mI2u1Rslr5OV6av33pVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWkASmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUBV8QAJVDQuH2QrAullb9khfLJ6Pn dpL01Bh/LeBSokkfVC1Ouesns14lwPwVvPeEtd6QlcIJWe5iUsWB0HJ3xQs36spO /Ule7DLFNDFPnAKCxEdqB88t20QCbl+UZspHA6WBLfNrLnlSPm+xcLlL2kN7x+rD yYrOir1w4mt4TURIyOM6L65utTtNg31ukVyPgr+LIBXYW41wn6tihaZ2W9K1JtaX GmVsQK1kjKaKyIzYygPbAFLb5OidXW3XrhJoFRSusHI6m6BF/Ty8Q1QCqSHycwt3 C8YcocvOdLjvxERJtqrFwJDPk2pC7QF+v2BQo2Ngk59R8mijIPMY4Bq8fu1lpvwx 8UsfC5QFd6Bhe7MAYg6xdqcmcNRHNEDpvUigP3gDdO5rHlxLHDqlgimxAieMlr14 hP+K0hG4esCKBDku5oWlxcL+WN/M21M/6tN9giPyTZ2L07P8PXbH7dM1bj7xeax+ 8DdHNv6c21TbjWwWZMm4pKI7id7Mzl+jtAKfC37TBCkre+Jcj9Sl21TykWjkQLcG ENE43W1ZmWGmbJwDmVUKxAZF1ycOSBYsLKK9kc1fBC3P0F9gG5UVLiFeU63B04l4 5VN7dzTWL9Qam4izYqKHLKmhRry9LVroakFp9usCQlLHkytIfd8GiGZSnz4IDvXZ 540ZZ6hoNbS2RM4Ou5Dw =cBjX -----END PGP SIGNATURE----- --DT0oDWAG2IJa4mI2u1Rslr5OV6av33pVC-- --===============6142498236825172790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6142498236825172790==--