From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932256AbdJJOF3 (ORCPT ); Tue, 10 Oct 2017 10:05:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44966 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932089AbdJJOF2 (ORCPT ); Tue, 10 Oct 2017 10:05:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 271CB4ACBA Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com Subject: Re: About commit 901ef845fa2469c ("selinux: allow per-file labeling for cgroupfs") To: Stephen Smalley , Antonio Murdaca Cc: Tejun Heo , selinux@tycho.nsa.gov, lkml , Paul Moore , Miroslav Grepl References: <8009753d-c022-12ec-406d-7d6cf01f5f73@redhat.com> <1507644412.30616.2.camel@tycho.nsa.gov> From: Waiman Long Organization: Red Hat Message-ID: <89c4fc8c-1931-582c-a7f3-8aa2ef14c3c4@redhat.com> Date: Tue, 10 Oct 2017 10:05:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1507644412.30616.2.camel@tycho.nsa.gov> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 10 Oct 2017 14:05:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/10/2017 10:06 AM, Stephen Smalley wrote: > On Fri, 2017-10-06 at 13:53 -0400, Waiman Long wrote: >> Antonio, >> >> I have a question about your 4.14 upstream commit 901ef845fa2469c >> ("selinux: allow per-file labeling for cgroupfs"). With that, I am no >> longer able to mount the cgroup2 filesystem with a 4.14 kernel. The >> problem is that your commit sets the SE_SBGENFS flag, which causes >> selinux to lookup the genfs database for a filesystem type match. >> However, the filesystem type "cgroup2" isn't in the genfs database in >> my >> RHEL7 based test system. The "cgroup" filesystem type is in the genfs >> database, >> so I have no problem with v1 cgroup mount. >> >> Do you know where the genfs database is defined? I need some way to >> add cgroup2 >> as a valid genfs fstype, or I have to manually back out the commit in >> order to >> do my cgroup2 testing. > It is part of the policy; you could add it via a policy module ala: > $ cat cgroup2.cil > (genfscon cgroup2 / (system_u object_r cgroup_t ((s0) (s0)))) > > $ sudo semodule -i cgroup2.cil Thanks for the workaround. I will try that next time. > That said, the fact that you can't even mount it without that is > arguably a bug/regression. I guess this is due to the ENOENT from > security_genfs_sid being propagated all the way up instead of just > leaving it unlabeled and permitting the mount to proceed. Yes, the mount command got the ENOENT error and it printed out some confusing message. Cheers, Longman