Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2678520pxj; Mon, 17 May 2021 07:20:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznm6AlWwgBI1Nt5YbGsVdhuA0edRljKgXy6mEw24jYplYebmYN4FpCro/58wezoNAUcYno X-Received: by 2002:a05:6402:4383:: with SMTP id o3mr266209edc.333.1621261240154; Mon, 17 May 2021 07:20:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621261240; cv=none; d=google.com; s=arc-20160816; b=m/+lXUyJTk/dLWoX4mqJsMHJpQfE1Lpgu22Y8xqkpHXiixXvs7OuJtLel8yKwGgGiS potfU6Dh8MahLH3fL/bkfgMoB66hM36spvBrsU7vfshziCe2IZJApw3O5/LaSk7q2S9A vTWPCX4l+jv6ZhyrR2KBVguzRQaUT0jPRKeQT9NELCR97zCKixM/OzdLRFgVDn7d+V70 jmkNyddL+N5deFOsn/+7PsOrjbkGrHg9+GdTUjjzZybKtqIJ+yUM8wkzCluUw1kbT4e9 gH3oY37BjUPg3bZTuy8ugoFkbyXEAWey+QNLKcsJjrAy9ZAVZobr1NHgrqgw8FjSDqi+ HrFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=O6gr94SKde4B9VQO2zKDR9PV8wUiJnB7z5q1aL8r6mE=; b=QsdX8iQqodDENIBiRosMKBbfbSScO+1fY575yTQwkQu9JdrcXKFUeWGqT2LfzwzdaM ymqntsJmitEknjHQWi4kRpvcqyPqasDk16RsRNKAZcJXqXsD+zUAW2IjJLHnf6M09VG+ puyahg0cjlFaGRvg88DbOIl6Nxy4jJAx29AKROrkvwmxIBRQTvw6rYQc7Z7t9ooa7hdj wDPkGfY4lK/uQ4T3EJ8DtDqDqbubduyP/toCVp6mWKJX8hHxuTVUtRn8ud/YFdj/LKe7 DGkpEI/6BLLwxXv/qehbF+bQw1VCEK2HJKRIWOIFzP0Wd2nOFML5iF6L+JFtzzeJwply Pdng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g6tnM7mX; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p8si16668197edj.611.2021.05.17.07.20.16; Mon, 17 May 2021 07:20:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g6tnM7mX; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237482AbhEQNrg (ORCPT + 99 others); Mon, 17 May 2021 09:47:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:33300 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235085AbhEQNrf (ORCPT ); Mon, 17 May 2021 09:47:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621259179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O6gr94SKde4B9VQO2zKDR9PV8wUiJnB7z5q1aL8r6mE=; b=g6tnM7mXjTreJhnuhfR+kd5FMMVZoBuDUyt0tCcQfrnIL40c8n6YxnYnSHx8JoCkVWnKHP AAIUdkKsZnPyOM00f0bG+boBkRSpDGU4jUaANt43lB5/GUuEQuUHaX5ml7znnEv2jSLrrt 0v/tkL8NMmOs6aBD+JNH3EZmC3j0kls= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-559-bh_HXi5iNC20Arm8nR1vpQ-1; Mon, 17 May 2021 09:46:17 -0400 X-MC-Unique: bh_HXi5iNC20Arm8nR1vpQ-1 Received: by mail-yb1-f200.google.com with SMTP id b66-20020a25cb450000b02905076ea039f1so8473607ybg.1 for ; Mon, 17 May 2021 06:46:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O6gr94SKde4B9VQO2zKDR9PV8wUiJnB7z5q1aL8r6mE=; b=BGbNLA4UtoFCZFe2V6TIxJqKae3NQSD61veTYfooKushHnaFM0oln1v+mwRKToOnoo SzbX6T2VSOawBqGjFVB8CmbnXrh4Ek82s/oclu1iSSTr5P6cFysLMXFGCXDYNwbKwtZl my9Sruqv44sDIIfpHnaLIUTt+85jby+Zt7Pkid9o0PqacIZ33W11COq+CyvPqxy2/bOD r5kcZXnv5L/exuBnfYGOBCa2yEqpNxD+Lib5JxNElPEV1AJhKUxzmMohb+9xae7oUfrP d0RT3JYYhU81VBGwChkFEPCY7EuZtMI/269QCw9MS5AGDoMz1uhHGN3u5Rt7EoE637dZ umWQ== X-Gm-Message-State: AOAM532QMFlJwvn8l37jwgSii358c/4FRSP2FE27nE6N+0IktShf1FYb 63I69Wve1SzAoH5RtiqkqytyrgpSm+FM/nmQbKbn/ksF6cUnmsWk3RVaA3v+MZXQhM133aTrsvW SwGxdfsCWjTV5WxChmIlLheOPR+A31FphUGKd X-Received: by 2002:a25:ed12:: with SMTP id k18mr18195723ybh.340.1621259177100; Mon, 17 May 2021 06:46:17 -0700 (PDT) X-Received: by 2002:a25:ed12:: with SMTP id k18mr18195683ybh.340.1621259176769; Mon, 17 May 2021 06:46:16 -0700 (PDT) MIME-Version: 1.0 References: <20210409111254.271800-1-omosnace@redhat.com> In-Reply-To: From: Ondrej Mosnacek Date: Mon, 17 May 2021 15:46:04 +0200 Message-ID: Subject: Re: [PATCH 0/2] vfs/security/NFS/btrfs: clean up and fix LSM option handling To: Al Viro Cc: Linux Security Module list , SElinux list , Linux FS Devel , linux-nfs , linux-btrfs@vger.kernel.org, Paul Moore , Olga Kornievskaia , David Howells , Stephen Smalley Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, Apr 9, 2021 at 7:39 PM Ondrej Mosnacek wrote: > On Fri, Apr 9, 2021 at 2:28 PM Al Viro wrote: > > On Fri, Apr 09, 2021 at 01:12:52PM +0200, Ondrej Mosnacek wrote: > > > This series attempts to clean up part of the mess that has grown around > > > the LSM mount option handling across different subsystems. > > > > I would not describe growing another FS_... flag > > Why is that necessarily a bad thing? > > > *AND* spreading the > > FS_BINARY_MOUNTDATA further, with rather weird semantics at that, > > as a cleanup of any sort. > > How is this spreading it further? The patches remove one (rather bad) > use of it in SELinux and somewhat reduce its use in btrfs. > > Hold on... actually I just realized that with FS_HANDLES_LSM_OPTS it > is possible to do btrfs without FS_BINARY_MOUNTDATA and also eliminate > the need for the workaround in vfs_parse_fs_param() (i.e. [2]). > > Basically instead of setting FS_BINARY_MOUNTDATA | FS_HANDLES_LSM_OPTS > in btrfs_fs_type and neither in btrfs_root_fs_type, it is enough to > set neither in btrfs_fs_type and only FS_HANDLES_LSM_OPTS in > btrfs_root_fs_type. The security opts are then applied in the outer > vfs_get_tree() call instead of the inner one, but the net effect is > the same. > > That should pretty much do away with both the non-legit users of > FS_BINARY_MOUNTDATA (selinux_set_mnt_opts() and btrfs). All the rest > seem to be in line with the semantic. > > Would [something like] the above stand any chance of getting your approval? So I posted this variant as v2 now: https://lore.kernel.org/selinux/20210517134201.29271-1-omosnace@redhat.com/T/ > > [2] https://lore.kernel.org/selinux/20210401065403.GA1363493@infradead.org/T/ -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.