Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] ima: cleanup the match_token policy code
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        linux-integrity@vger.kernel.org,
        James Morris James Morris <jmorris@namei.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Date:   Tue, 18 Dec 2018 00:04:41 -0500
In-Reply-To: <20181218040629.GT2217@ZenIV.linux.org.uk>
References: <1545092089.4206.5.camel@linux.ibm.com>
         <CAHk-=whEb_vShPGCK80_tspsyw12G6mHLQkMDiSP0GWWHroqqA@mail.gmail.com>
         <20181218013348.GR2217@ZenIV.linux.org.uk>
         <1545102007.4206.15.camel@linux.ibm.com>
         <20181218040629.GT2217@ZenIV.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <1545109481.4206.36.camel@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2018-12-18 at 04:06 +0000, Al Viro wrote:
> On Mon, Dec 17, 2018 at 10:00:07PM -0500, Mimi Zohar wrote:
> 
> > Could you expand on commit 5b2ea6199614 ("selinux: switch away from
> > match_token()") patch description.  All that it says is "It's not a
> > good fit, unfortunately, and the next step will make it even less so.
> > Open-code what we need here."  And there's even less for the
> > equivalent Smack patch, which just says "same issue as with
> > selinux...".
> 
> match_token() would require messing around with strsep() or something
> equivalent.  It's not a regex; foo=%s has no idea that comma is in any
> way special, etc.
> 
> As for the next commit...  Killing the Cthulhu-awful mess in
> selinux_sb_eat_lsm_opts() (allocating two temproraries, concatenating
> (comma-separated) non-LSM options into one, concatenating (pipe-separated)
> dequoted LSM options into another, then splitting that another by '|'
> instances and figuring out which option each piece is, etc.)
> is a Good Thing(tm).  And having to dance around the needs of
> match_token() adds extra headache, for no good reason.

Ok, so it is this particular combination of things, not the general
usage of strsep or match_token that you're objecting to.  So fixing
the other match_token non-LSM instances is fine.

To prevent the enumeration and the match_table from going out of sync,
I was thinking about defining a macro to create the match_table_t:

#define __policy_tokens_match(ENUM, str) {Opt_ ## ENUM, #str},

static const match_table_t policy_tokens = {
        __policy_tokens_id(__policy_tokens_match)
};

and the enumeration:

enum policy_tokens_id {
        __policy_tokens_id(__policy_tokens_enumify)
};

Mimi