From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_HIGH,UNPARSEABLE_RELAY,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0AD9C46464 for ; Sat, 11 Aug 2018 00:39:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E99F219C6 for ; Sat, 11 Aug 2018 00:39:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="JRfTZtg2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E99F219C6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727198AbeHKDL5 (ORCPT ); Fri, 10 Aug 2018 23:11:57 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:36340 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726903AbeHKDL5 (ORCPT ); Fri, 10 Aug 2018 23:11:57 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w7B0d0Yd178763; Sat, 11 Aug 2018 00:39:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2018-07-02; bh=kGriiRvaEJZkhi+Lyu+MC6HbJz34ewVUpzQb2zRP+9I=; b=JRfTZtg2ad5i4KaKfQ7EyJB9L+VM8BHmmfvxLpU3mOcDIrIrzEk2mhP4Bc9CLF1efLiw 5YwHJ8+yceqUOfdkSk5pKE5zBk4Ulfimn3QDWXK1Xrvn1wcrRpyCaJ+0/qjHj1j9zzk3 XCYugwZh2MQwhX9PnrsjDNrYk//qdylb3+r4wpGvwKmJR0H3km+3vEf/iABd8KJd4MsL KT9DJLTtPUf3JCrxC1IU/VotdUvHvWeEMeAUmQkrSHiwy/QreIvsCWhNWDCHS7R5Ckay BlKV48G3trFXmcFhA6IIbSRo5dtfDmMRINu/4xiw8ZSxe5HbL5pPMpODYXD3P+2uCY1p 4g== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2kn43p9b5u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Aug 2018 00:39:00 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w7B0d0Q3007194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Aug 2018 00:39:00 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w7B0ctwS002509; Sat, 11 Aug 2018 00:38:55 GMT Received: from localhost (/67.169.218.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2018 17:38:55 -0700 Date: Fri, 10 Aug 2018 17:38:52 -0700 From: "Darrick J. Wong" To: "Theodore Y. Ts'o" , Andy Lutomirski , David Howells , "Eric W. Biederman" , Al Viro , John Johansen , Tejun Heo , SELinux-NSA , Paul Moore , Li Zefan , Linux API , apparmor@lists.ubuntu.com, Casey Schaufler , Fenghua Yu , Greg Kroah-Hartman , Eric Biggers , LSM List , Tetsuo Handa , Johannes Weiner , Stephen Smalley , tomoyo-dev-en@lists.sourceforge.jp, "open list:CONTROL GROUP (CGROUP)" , Linus Torvalds , Linux FS Devel , LKML , Miklos Szeredi Subject: Re: BUG: Mount ignores mount options Message-ID: <20180811003852.GA10463@magnolia> References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> <20180810204639.GI627@thunk.org> <20180810221234.GC4211@magnolia> <20180810235447.GK627@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180810235447.GK627@thunk.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8981 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808110005 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 10, 2018 at 07:54:47PM -0400, Theodore Y. Ts'o wrote: > On Fri, Aug 10, 2018 at 03:12:34PM -0700, Darrick J. Wong wrote: > > Hey now, there was a little more nuance to it than that[1][2]. The > > complaint in the first instance had much more to do with breaking > > existing V4 filesystems by adding format requirements that mkfs didn't > > know about when the filesystem was created. Yes, you can create V4 > > filesystems that will hang the system if the log was totally unformatted > > and metadata updates are made, but OTOH it's fairly obvious when that > > happens, you have to be root to mount a disk filesystem, and we try to > > avoid breaking existing users. > > I wasn't thinking about syzbot reports; I've largely written them off > as far as file system testing is concerned, but rather Wen Xu at > Georgia Tech, who is much more reasonable than Dmitry, and has helpeyd > me out a lot; and has complained that the XFS folks haven't been > engaging with him. Ahh, ok. Yes, Wen has been easier to work with, and gives out filesystem images. Hm, I'll go comb the bugzilla again... > In either case, both security researchers are fuzzing file system > images, and then fixing the checksums, and discovering that this can > lead to kernel crashes, and in a few cases, buffer overruns that can > lead to potential privilege escalations. Wen can generate reports > faster than syzbot, but at least he gives me file system images (as > opposed to having to dig them out of syzbot repro C files) and he > actually does some analysis and explains what he thinks is going on. (FWIW I tried to figure out how to add fs image dumping to syzbot and whoah that was horrifying. > I don't think anyone was claiming that format requirements should be > added to ext4 or xfs file systems. But rather, that kernel code > should be made more robust against maliciously corrupted file system > images that have valid checksums. I've been more willing to work with > Wen; Dave has expressed the opinion that these are not realistic bug > reports, and since only root can mount file systems, it's not high > priority. I don't think they're high priority either, but they're at least worth /some/ attention. > The reason why I bring this up here is that in container land, there > are those who believe that "container root" should be able to mount > file systems, and if the "container root" isn't trusted, the fact that > the "container root" can crash the host kernel, or worse, corrupt the > host kernel and break out of the container as a result, that would be > sad. > > I was pretty sure most file system developers are on the same page > that allowing untrusted "container roots" the ability to mount > arbitrary block device file systems is insanity. Agreed. > Whether or not we try to fix these sorts of bugs submitted by security > researchers. :-) and agreed. :) --D > - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Darrick J. Wong" Subject: Re: BUG: Mount ignores mount options Date: Fri, 10 Aug 2018 17:38:52 -0700 Message-ID: <20180811003852.GA10463@magnolia> References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> <20180810204639.GI627@thunk.org> <20180810221234.GC4211@magnolia> <20180810235447.GK627@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20180810235447.GK627-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apparmor-bounces-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org Sender: "AppArmor" To: "Theodore Y. Ts'o" , Andy Lutomirski , David Howells , "Eric W. Biederman" , Al Viro , John Johansen , Tejun Heo , SELinux-NSA , Paul Moore , Li Zefan , Linux API , apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org, Casey Schaufler , Fenghua Yu , Greg Kroah-Hartman , Eric Biggers , LSM List , Tetsuo Handa , Johannes Weiner , Stephen Smalley , tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org, "open list:CONTROL GROUP (CGROUP)" List-Id: linux-api@vger.kernel.org T24gRnJpLCBBdWcgMTAsIDIwMTggYXQgMDc6NTQ6NDdQTSAtMDQwMCwgVGhlb2RvcmUgWS4gVHMn byB3cm90ZToKPiBPbiBGcmksIEF1ZyAxMCwgMjAxOCBhdCAwMzoxMjozNFBNIC0wNzAwLCBEYXJy aWNrIEouIFdvbmcgd3JvdGU6Cj4gPiBIZXkgbm93LCB0aGVyZSB3YXMgYSBsaXR0bGUgbW9yZSBu dWFuY2UgdG8gaXQgdGhhbiB0aGF0WzFdWzJdLiAgVGhlCj4gPiBjb21wbGFpbnQgaW4gdGhlIGZp cnN0IGluc3RhbmNlIGhhZCBtdWNoIG1vcmUgdG8gZG8gd2l0aCBicmVha2luZwo+ID4gZXhpc3Rp bmcgVjQgZmlsZXN5c3RlbXMgYnkgYWRkaW5nIGZvcm1hdCByZXF1aXJlbWVudHMgdGhhdCBta2Zz IGRpZG4ndAo+ID4ga25vdyBhYm91dCB3aGVuIHRoZSBmaWxlc3lzdGVtIHdhcyBjcmVhdGVkLiAg WWVzLCB5b3UgY2FuIGNyZWF0ZSBWNAo+ID4gZmlsZXN5c3RlbXMgdGhhdCB3aWxsIGhhbmcgdGhl IHN5c3RlbSBpZiB0aGUgbG9nIHdhcyB0b3RhbGx5IHVuZm9ybWF0dGVkCj4gPiBhbmQgbWV0YWRh dGEgdXBkYXRlcyBhcmUgbWFkZSwgYnV0IE9UT0ggaXQncyBmYWlybHkgb2J2aW91cyB3aGVuIHRo YXQKPiA+IGhhcHBlbnMsIHlvdSBoYXZlIHRvIGJlIHJvb3QgdG8gbW91bnQgYSBkaXNrIGZpbGVz eXN0ZW0sIGFuZCB3ZSB0cnkgdG8KPiA+IGF2b2lkIGJyZWFraW5nIGV4aXN0aW5nIHVzZXJzLgo+ IAo+IEkgd2Fzbid0IHRoaW5raW5nIGFib3V0IHN5emJvdCByZXBvcnRzOyBJJ3ZlIGxhcmdlbHkg d3JpdHRlbiB0aGVtIG9mZgo+IGFzIGZhciBhcyBmaWxlIHN5c3RlbSB0ZXN0aW5nIGlzIGNvbmNl cm5lZCwgYnV0IHJhdGhlciBXZW4gWHUgYXQKPiBHZW9yZ2lhIFRlY2gsIHdobyBpcyBtdWNoIG1v cmUgcmVhc29uYWJsZSB0aGFuIERtaXRyeSwgYW5kIGhhcyBoZWxwZXlkCj4gbWUgb3V0IGEgbG90 OyBhbmQgaGFzIGNvbXBsYWluZWQgdGhhdCB0aGUgWEZTIGZvbGtzIGhhdmVuJ3QgYmVlbgo+IGVu Z2FnaW5nIHdpdGggaGltLgoKQWhoLCBvay4gIFllcywgV2VuIGhhcyBiZWVuIGVhc2llciB0byB3 b3JrIHdpdGgsIGFuZCBnaXZlcyBvdXQKZmlsZXN5c3RlbSBpbWFnZXMuICBIbSwgSSdsbCBnbyBj b21iIHRoZSBidWd6aWxsYSBhZ2Fpbi4uLgoKPiBJbiBlaXRoZXIgY2FzZSwgYm90aCBzZWN1cml0 eSByZXNlYXJjaGVycyBhcmUgZnV6emluZyBmaWxlIHN5c3RlbQo+IGltYWdlcywgYW5kIHRoZW4g Zml4aW5nIHRoZSBjaGVja3N1bXMsIGFuZCBkaXNjb3ZlcmluZyB0aGF0IHRoaXMgY2FuCj4gbGVh ZCB0byBrZXJuZWwgY3Jhc2hlcywgYW5kIGluIGEgZmV3IGNhc2VzLCBidWZmZXIgb3ZlcnJ1bnMg dGhhdCBjYW4KPiBsZWFkIHRvIHBvdGVudGlhbCBwcml2aWxlZ2UgZXNjYWxhdGlvbnMuICBXZW4g Y2FuIGdlbmVyYXRlIHJlcG9ydHMKPiBmYXN0ZXIgdGhhbiBzeXpib3QsIGJ1dCBhdCBsZWFzdCBo ZSBnaXZlcyBtZSBmaWxlIHN5c3RlbSBpbWFnZXMgKGFzCj4gb3Bwb3NlZCB0byBoYXZpbmcgdG8g ZGlnIHRoZW0gb3V0IG9mIHN5emJvdCByZXBybyBDIGZpbGVzKSBhbmQgaGUKPiBhY3R1YWxseSBk b2VzIHNvbWUgYW5hbHlzaXMgYW5kIGV4cGxhaW5zIHdoYXQgaGUgdGhpbmtzIGlzIGdvaW5nIG9u LgoKKEZXSVcgSSB0cmllZCB0byBmaWd1cmUgb3V0IGhvdyB0byBhZGQgZnMgaW1hZ2UgZHVtcGlu ZyB0byBzeXpib3QgYW5kCndob2FoIHRoYXQgd2FzIGhvcnJpZnlpbmcuCgo+IEkgZG9uJ3QgdGhp bmsgYW55b25lIHdhcyBjbGFpbWluZyB0aGF0IGZvcm1hdCByZXF1aXJlbWVudHMgc2hvdWxkIGJl Cj4gYWRkZWQgdG8gZXh0NCBvciB4ZnMgZmlsZSBzeXN0ZW1zLiAgQnV0IHJhdGhlciwgdGhhdCBr ZXJuZWwgY29kZQo+IHNob3VsZCBiZSBtYWRlIG1vcmUgcm9idXN0IGFnYWluc3QgbWFsaWNpb3Vz bHkgY29ycnVwdGVkIGZpbGUgc3lzdGVtCj4gaW1hZ2VzIHRoYXQgaGF2ZSB2YWxpZCBjaGVja3N1 bXMuICBJJ3ZlIGJlZW4gbW9yZSB3aWxsaW5nIHRvIHdvcmsgd2l0aAo+IFdlbjsgRGF2ZSBoYXMg ZXhwcmVzc2VkIHRoZSBvcGluaW9uIHRoYXQgdGhlc2UgYXJlIG5vdCByZWFsaXN0aWMgYnVnCj4g cmVwb3J0cywgYW5kIHNpbmNlIG9ubHkgcm9vdCBjYW4gbW91bnQgZmlsZSBzeXN0ZW1zLCBpdCdz IG5vdCBoaWdoCj4gcHJpb3JpdHkuCgpJIGRvbid0IHRoaW5rIHRoZXkncmUgaGlnaCBwcmlvcml0 eSBlaXRoZXIsIGJ1dCB0aGV5J3JlIGF0IGxlYXN0IHdvcnRoCi9zb21lLyBhdHRlbnRpb24uCgo+ IFRoZSByZWFzb24gd2h5IEkgYnJpbmcgdGhpcyB1cCBoZXJlIGlzIHRoYXQgaW4gY29udGFpbmVy IGxhbmQsIHRoZXJlCj4gYXJlIHRob3NlIHdobyBiZWxpZXZlIHRoYXQgImNvbnRhaW5lciByb290 IiBzaG91bGQgYmUgYWJsZSB0byBtb3VudAo+IGZpbGUgc3lzdGVtcywgYW5kIGlmIHRoZSAiY29u dGFpbmVyIHJvb3QiIGlzbid0IHRydXN0ZWQsIHRoZSBmYWN0IHRoYXQKPiB0aGUgImNvbnRhaW5l ciByb290IiBjYW4gY3Jhc2ggdGhlIGhvc3Qga2VybmVsLCBvciB3b3JzZSwgY29ycnVwdCB0aGUK PiBob3N0IGtlcm5lbCBhbmQgYnJlYWsgb3V0IG9mIHRoZSBjb250YWluZXIgYXMgYSByZXN1bHQs IHRoYXQgd291bGQgYmUKPiBzYWQuCj4gCj4gSSB3YXMgcHJldHR5IHN1cmUgbW9zdCBmaWxlIHN5 c3RlbSBkZXZlbG9wZXJzIGFyZSBvbiB0aGUgc2FtZSBwYWdlCj4gdGhhdCBhbGxvd2luZyB1bnRy dXN0ZWQgImNvbnRhaW5lciByb290cyIgdGhlIGFiaWxpdHkgdG8gbW91bnQKPiBhcmJpdHJhcnkg YmxvY2sgZGV2aWNlIGZpbGUgc3lzdGVtcyBpcyBpbnNhbml0eS4KCkFncmVlZC4KCj4gV2hldGhl ciBvciBub3Qgd2UgdHJ5IHRvIGZpeCB0aGVzZSBzb3J0cyBvZiBidWdzIHN1Ym1pdHRlZCBieSBz ZWN1cml0eQo+IHJlc2VhcmNoZXJzLiAgOi0pCgphbmQgYWdyZWVkLiA6KQoKLS1ECgo+IAkgIAkg ICAgICAgCSAgICAJICAgICAgIAkJICAtIFRlZAoKLS0gCkFwcEFybW9yIG1haWxpbmcgbGlzdApB cHBBcm1vckBsaXN0cy51YnVudHUuY29tCk1vZGlmeSBzZXR0aW5ncyBvciB1bnN1YnNjcmliZSBh dDogaHR0cHM6Ly9saXN0cy51YnVudHUuY29tL21haWxtYW4vbGlzdGluZm8vYXBwYXJtb3IK From mboxrd@z Thu Jan 1 00:00:00 1970 From: darrick.wong@oracle.com (Darrick J. Wong) Date: Fri, 10 Aug 2018 17:38:52 -0700 Subject: BUG: Mount ignores mount options In-Reply-To: <20180810235447.GK627@thunk.org> References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> <20180810204639.GI627@thunk.org> <20180810221234.GC4211@magnolia> <20180810235447.GK627@thunk.org> Message-ID: <20180811003852.GA10463@magnolia> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Fri, Aug 10, 2018 at 07:54:47PM -0400, Theodore Y. Ts'o wrote: > On Fri, Aug 10, 2018 at 03:12:34PM -0700, Darrick J. Wong wrote: > > Hey now, there was a little more nuance to it than that[1][2]. The > > complaint in the first instance had much more to do with breaking > > existing V4 filesystems by adding format requirements that mkfs didn't > > know about when the filesystem was created. Yes, you can create V4 > > filesystems that will hang the system if the log was totally unformatted > > and metadata updates are made, but OTOH it's fairly obvious when that > > happens, you have to be root to mount a disk filesystem, and we try to > > avoid breaking existing users. > > I wasn't thinking about syzbot reports; I've largely written them off > as far as file system testing is concerned, but rather Wen Xu at > Georgia Tech, who is much more reasonable than Dmitry, and has helpeyd > me out a lot; and has complained that the XFS folks haven't been > engaging with him. Ahh, ok. Yes, Wen has been easier to work with, and gives out filesystem images. Hm, I'll go comb the bugzilla again... > In either case, both security researchers are fuzzing file system > images, and then fixing the checksums, and discovering that this can > lead to kernel crashes, and in a few cases, buffer overruns that can > lead to potential privilege escalations. Wen can generate reports > faster than syzbot, but at least he gives me file system images (as > opposed to having to dig them out of syzbot repro C files) and he > actually does some analysis and explains what he thinks is going on. (FWIW I tried to figure out how to add fs image dumping to syzbot and whoah that was horrifying. > I don't think anyone was claiming that format requirements should be > added to ext4 or xfs file systems. But rather, that kernel code > should be made more robust against maliciously corrupted file system > images that have valid checksums. I've been more willing to work with > Wen; Dave has expressed the opinion that these are not realistic bug > reports, and since only root can mount file systems, it's not high > priority. I don't think they're high priority either, but they're at least worth /some/ attention. > The reason why I bring this up here is that in container land, there > are those who believe that "container root" should be able to mount > file systems, and if the "container root" isn't trusted, the fact that > the "container root" can crash the host kernel, or worse, corrupt the > host kernel and break out of the container as a result, that would be > sad. > > I was pretty sure most file system developers are on the same page > that allowing untrusted "container roots" the ability to mount > arbitrary block device file systems is insanity. Agreed. > Whether or not we try to fix these sorts of bugs submitted by security > researchers. :-) and agreed. :) --D > - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Darrick J. Wong" Subject: Re: BUG: Mount ignores mount options Date: Fri, 10 Aug 2018 17:38:52 -0700 Message-ID: <20180811003852.GA10463@magnolia> References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> <20180810204639.GI627@thunk.org> <20180810221234.GC4211@magnolia> <20180810235447.GK627@thunk.org> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2018-07-02; bh=kGriiRvaEJZkhi+Lyu+MC6HbJz34ewVUpzQb2zRP+9I=; b=JRfTZtg2ad5i4KaKfQ7EyJB9L+VM8BHmmfvxLpU3mOcDIrIrzEk2mhP4Bc9CLF1efLiw 5YwHJ8+yceqUOfdkSk5pKE5zBk4Ulfimn3QDWXK1Xrvn1wcrRpyCaJ+0/qjHj1j9zzk3 XCYugwZh2MQwhX9PnrsjDNrYk//qdylb3+r4wpGvwKmJR0H3km+3vEf/iABd8KJd4MsL KT9DJLTtPUf3JCrxC1IU/VotdUvHvWeEMeAUmQkrSHiwy/QreIvsCWhNWDCHS7R5Ckay BlKV48G3trFXmcFhA6IIbSRo5dtfDmMRINu/4xiw8ZSxe5HbL5pPMpODYXD3P+2uCY1p 4g== Content-Disposition: inline In-Reply-To: <20180810235447.GK627-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apparmor-bounces-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org Sender: "AppArmor" Content-Type: text/plain; charset="us-ascii" To: "Theodore Y. Ts'o" , Andy Lutomirski , David Howells , "Eric W. Biederman" , Al Viro , John Johansen , Tejun Heo , SELinux-NSA , Paul Moore , Li Zefan , Linux API , apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org, Casey Schaufler , Fenghua Yu , Greg Kroah-Hartman , Eric Biggers , LSM List , Tetsuo Handa , Johannes Weiner , Stephen Smalley , tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org, "open list:CONTROL GROUP (CGROUP)" , Linus Torvalds <> T24gRnJpLCBBdWcgMTAsIDIwMTggYXQgMDc6NTQ6NDdQTSAtMDQwMCwgVGhlb2RvcmUgWS4gVHMn byB3cm90ZToKPiBPbiBGcmksIEF1ZyAxMCwgMjAxOCBhdCAwMzoxMjozNFBNIC0wNzAwLCBEYXJy aWNrIEouIFdvbmcgd3JvdGU6Cj4gPiBIZXkgbm93LCB0aGVyZSB3YXMgYSBsaXR0bGUgbW9yZSBu dWFuY2UgdG8gaXQgdGhhbiB0aGF0WzFdWzJdLiAgVGhlCj4gPiBjb21wbGFpbnQgaW4gdGhlIGZp cnN0IGluc3RhbmNlIGhhZCBtdWNoIG1vcmUgdG8gZG8gd2l0aCBicmVha2luZwo+ID4gZXhpc3Rp bmcgVjQgZmlsZXN5c3RlbXMgYnkgYWRkaW5nIGZvcm1hdCByZXF1aXJlbWVudHMgdGhhdCBta2Zz IGRpZG4ndAo+ID4ga25vdyBhYm91dCB3aGVuIHRoZSBmaWxlc3lzdGVtIHdhcyBjcmVhdGVkLiAg WWVzLCB5b3UgY2FuIGNyZWF0ZSBWNAo+ID4gZmlsZXN5c3RlbXMgdGhhdCB3aWxsIGhhbmcgdGhl IHN5c3RlbSBpZiB0aGUgbG9nIHdhcyB0b3RhbGx5IHVuZm9ybWF0dGVkCj4gPiBhbmQgbWV0YWRh dGEgdXBkYXRlcyBhcmUgbWFkZSwgYnV0IE9UT0ggaXQncyBmYWlybHkgb2J2aW91cyB3aGVuIHRo YXQKPiA+IGhhcHBlbnMsIHlvdSBoYXZlIHRvIGJlIHJvb3QgdG8gbW91bnQgYSBkaXNrIGZpbGVz eXN0ZW0sIGFuZCB3ZSB0cnkgdG8KPiA+IGF2b2lkIGJyZWFraW5nIGV4aXN0aW5nIHVzZXJzLgo+ IAo+IEkgd2Fzbid0IHRoaW5raW5nIGFib3V0IHN5emJvdCByZXBvcnRzOyBJJ3ZlIGxhcmdlbHkg d3JpdHRlbiB0aGVtIG9mZgo+IGFzIGZhciBhcyBmaWxlIHN5c3RlbSB0ZXN0aW5nIGlzIGNvbmNl cm5lZCwgYnV0IHJhdGhlciBXZW4gWHUgYXQKPiBHZW9yZ2lhIFRlY2gsIHdobyBpcyBtdWNoIG1v cmUgcmVhc29uYWJsZSB0aGFuIERtaXRyeSwgYW5kIGhhcyBoZWxwZXlkCj4gbWUgb3V0IGEgbG90 OyBhbmQgaGFzIGNvbXBsYWluZWQgdGhhdCB0aGUgWEZTIGZvbGtzIGhhdmVuJ3QgYmVlbgo+IGVu Z2FnaW5nIHdpdGggaGltLgoKQWhoLCBvay4gIFllcywgV2VuIGhhcyBiZWVuIGVhc2llciB0byB3 b3JrIHdpdGgsIGFuZCBnaXZlcyBvdXQKZmlsZXN5c3RlbSBpbWFnZXMuICBIbSwgSSdsbCBnbyBj b21iIHRoZSBidWd6aWxsYSBhZ2Fpbi4uLgoKPiBJbiBlaXRoZXIgY2FzZSwgYm90aCBzZWN1cml0 eSByZXNlYXJjaGVycyBhcmUgZnV6emluZyBmaWxlIHN5c3RlbQo+IGltYWdlcywgYW5kIHRoZW4g Zml4aW5nIHRoZSBjaGVja3N1bXMsIGFuZCBkaXNjb3ZlcmluZyB0aGF0IHRoaXMgY2FuCj4gbGVh ZCB0byBrZXJuZWwgY3Jhc2hlcywgYW5kIGluIGEgZmV3IGNhc2VzLCBidWZmZXIgb3ZlcnJ1bnMg dGhhdCBjYW4KPiBsZWFkIHRvIHBvdGVudGlhbCBwcml2aWxlZ2UgZXNjYWxhdGlvbnMuICBXZW4g Y2FuIGdlbmVyYXRlIHJlcG9ydHMKPiBmYXN0ZXIgdGhhbiBzeXpib3QsIGJ1dCBhdCBsZWFzdCBo ZSBnaXZlcyBtZSBmaWxlIHN5c3RlbSBpbWFnZXMgKGFzCj4gb3Bwb3NlZCB0byBoYXZpbmcgdG8g ZGlnIHRoZW0gb3V0IG9mIHN5emJvdCByZXBybyBDIGZpbGVzKSBhbmQgaGUKPiBhY3R1YWxseSBk b2VzIHNvbWUgYW5hbHlzaXMgYW5kIGV4cGxhaW5zIHdoYXQgaGUgdGhpbmtzIGlzIGdvaW5nIG9u LgoKKEZXSVcgSSB0cmllZCB0byBmaWd1cmUgb3V0IGhvdyB0byBhZGQgZnMgaW1hZ2UgZHVtcGlu ZyB0byBzeXpib3QgYW5kCndob2FoIHRoYXQgd2FzIGhvcnJpZnlpbmcuCgo+IEkgZG9uJ3QgdGhp bmsgYW55b25lIHdhcyBjbGFpbWluZyB0aGF0IGZvcm1hdCByZXF1aXJlbWVudHMgc2hvdWxkIGJl Cj4gYWRkZWQgdG8gZXh0NCBvciB4ZnMgZmlsZSBzeXN0ZW1zLiAgQnV0IHJhdGhlciwgdGhhdCBr ZXJuZWwgY29kZQo+IHNob3VsZCBiZSBtYWRlIG1vcmUgcm9idXN0IGFnYWluc3QgbWFsaWNpb3Vz bHkgY29ycnVwdGVkIGZpbGUgc3lzdGVtCj4gaW1hZ2VzIHRoYXQgaGF2ZSB2YWxpZCBjaGVja3N1 bXMuICBJJ3ZlIGJlZW4gbW9yZSB3aWxsaW5nIHRvIHdvcmsgd2l0aAo+IFdlbjsgRGF2ZSBoYXMg ZXhwcmVzc2VkIHRoZSBvcGluaW9uIHRoYXQgdGhlc2UgYXJlIG5vdCByZWFsaXN0aWMgYnVnCj4g cmVwb3J0cywgYW5kIHNpbmNlIG9ubHkgcm9vdCBjYW4gbW91bnQgZmlsZSBzeXN0ZW1zLCBpdCdz IG5vdCBoaWdoCj4gcHJpb3JpdHkuCgpJIGRvbid0IHRoaW5rIHRoZXkncmUgaGlnaCBwcmlvcml0 eSBlaXRoZXIsIGJ1dCB0aGV5J3JlIGF0IGxlYXN0IHdvcnRoCi9zb21lLyBhdHRlbnRpb24uCgo+ IFRoZSByZWFzb24gd2h5IEkgYnJpbmcgdGhpcyB1cCBoZXJlIGlzIHRoYXQgaW4gY29udGFpbmVy IGxhbmQsIHRoZXJlCj4gYXJlIHRob3NlIHdobyBiZWxpZXZlIHRoYXQgImNvbnRhaW5lciByb290 IiBzaG91bGQgYmUgYWJsZSB0byBtb3VudAo+IGZpbGUgc3lzdGVtcywgYW5kIGlmIHRoZSAiY29u dGFpbmVyIHJvb3QiIGlzbid0IHRydXN0ZWQsIHRoZSBmYWN0IHRoYXQKPiB0aGUgImNvbnRhaW5l ciByb290IiBjYW4gY3Jhc2ggdGhlIGhvc3Qga2VybmVsLCBvciB3b3JzZSwgY29ycnVwdCB0aGUK PiBob3N0IGtlcm5lbCBhbmQgYnJlYWsgb3V0IG9mIHRoZSBjb250YWluZXIgYXMgYSByZXN1bHQs IHRoYXQgd291bGQgYmUKPiBzYWQuCj4gCj4gSSB3YXMgcHJldHR5IHN1cmUgbW9zdCBmaWxlIHN5 c3RlbSBkZXZlbG9wZXJzIGFyZSBvbiB0aGUgc2FtZSBwYWdlCj4gdGhhdCBhbGxvd2luZyB1bnRy dXN0ZWQgImNvbnRhaW5lciByb290cyIgdGhlIGFiaWxpdHkgdG8gbW91bnQKPiBhcmJpdHJhcnkg YmxvY2sgZGV2aWNlIGZpbGUgc3lzdGVtcyBpcyBpbnNhbml0eS4KCkFncmVlZC4KCj4gV2hldGhl ciBvciBub3Qgd2UgdHJ5IHRvIGZpeCB0aGVzZSBzb3J0cyBvZiBidWdzIHN1Ym1pdHRlZCBieSBz ZWN1cml0eQo+IHJlc2VhcmNoZXJzLiAgOi0pCgphbmQgYWdyZWVkLiA6KQoKLS1ECgo+IAkgIAkg ICAgICAgCSAgICAJICAgICAgIAkJICAtIFRlZAoKLS0gCkFwcEFybW9yIG1haWxpbmcgbGlzdApB cHBBcm1vckBsaXN0cy51YnVudHUuY29tCk1vZGlmeSBzZXR0aW5ncyBvciB1bnN1YnNjcmliZSBh dDogaHR0cHM6Ly9saXN0cy51YnVudHUuY29tL21haWxtYW4vbGlzdGluZm8vYXBwYXJtb3IK