From owner-freebsd-geom@FreeBSD.ORG  Wed Jul 31 09:10:11 2013
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 76AA2DE8;
 Wed, 31 Jul 2013 09:10:11 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru
 [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 39B0D23DC;
 Wed, 31 Jul 2013 09:10:10 +0000 (UTC)
Received: from lion.home.serebryakov.spb.ru (unknown
 [IPv6:2001:470:923f:1:2418:88c5:96ef:35b4])
 (Authenticated sender: lev@serebryakov.spb.ru)
 by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EB9D54AC57;
 Wed, 31 Jul 2013 13:10:01 +0400 (MSK)
Date: Wed, 31 Jul 2013 13:09:56 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Organization: FreeBSD
X-Priority: 3 (Normal)
Message-ID: <447183917.20130731130956@serebryakov.spb.ru>
To: freebsd-geom@freebsd.org, freebsd-arch@FreeBSD.org
Subject: [PROPOSAL] GEOM probing/tasting firewall
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: lev@FreeBSD.org
List-Id: GEOM-specific discussions and implementations
 <freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-geom>,
 <mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
 <mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 09:10:11 -0000

Hello, Freebsd-geom.

  After message to GEOM list by Rotate 13 <rabgvzr@gmail.com> I was "forced"
 to write this proposal.

  For first time this idea was formulated in Jabber talk with friend of
 mine, who uses FreeBSD for massive iSCSI hosting on ZVOLs. He has problems
 with tasting these ZVOLs, which contain different types of data (Windows
 disks, Linux disks, FreeBSD disks, etc). Here are label conflicts, strange
 messages about corrupted GPTs, etc. So, it looks like to have configurable
 way to prevent some GEOM tasting is good idea.

  I propose to have mechanism, modelled after ipfw, to filter all new GEOMs
 before passing it to class tasting mechanisms.

  It will be chain of (numbered) rules with format:

rule ::= (enable | disable) ['taste'] ['by'] <consumer-spec> [['of'] <conditions>]
consumer-spec ::= 'all' | <class-name>
conditions ::= <condtition> ('and' <condition>)*
condition ::= [not] ( 'class' <mask>' | 'name' <mask> | 'path' <mask> )
mask ::= <shell-like-glob>

 'path' means "path in /dev hierarchy' here.

 Of course, default last (and only one, if user does nothing) rule must be

 "enable taste by all"

 Maybe, <conditions> could be expanded to full-featured boolean expressions,
with parenthesis and 'or' operator, it is possible, but ommitted in this
proposal to save time (I don't want to write out full expression EBNF now).

 Every added rule should trigger spoiling and re-tasting of all providers,
which are not opened by upper level (so, already mounted file systems will
prevent GEOMs from disappearing even if new rule forbid such tasting).

 I could write prototype code for this proposal, it it is not rejected right
now :)

-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>