From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Arturo Borrero Gonzalez <arturo@debian.org>
Cc: Ismo Puustinen <ismo.puustinen@intel.com>,
Netfilter Development Mailing list
<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH 1/3] scanner: add files in include dirs in alphabetical order.
Date: Mon, 12 Jun 2017 10:10:07 +0200 [thread overview]
Message-ID: <20170612081007.GA2462@salvia> (raw)
In-Reply-To: <CAOkSjBiTkEbhLtmRQq4ifYv7QQ352tCLfd6kT9DN=XsB=KtR7Q@mail.gmail.com>
On Thu, Jun 08, 2017 at 06:37:57PM +0200, Arturo Borrero Gonzalez wrote:
> On 8 June 2017 at 12:17, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > Then, to keep it consistent, we should also display a warning in
> > include file with no .nft postfix. At deprecate the existing behaviour
> > at some point, ie. bail out if you include a file that has no trailing
> > .nft in its name.
> >
> > If we follow this path, all ruleset file will end up using .nft as
> > a trailer in the name.
> >
>
> but perhaps it makes sense to differentiate two cases:
> * include a single file: accept arbitrary names
> * include a whole dir: accept only files ending in .nft
>
> This seems to be what sysctl(8) does when loading a single file vs a directory.
> I'm thinking in a case where you have a README in the directory or
> other unrelated file.
I see, it makes sense indeed to have a way to skip files you don't
want. But I still would like this behaviour is consistent.
> If the idea is to allow drop files (a good idea indeed), then being
> explicit is a good approach.
>
> > Is there any other similar software following this approach? How is
> > 'ferm' doing this?
>
> ferm seems to load arbitrary files. In the docs they suggest using
> .ferm files but the code
> seems to allow whatever.
> However, they have a set of regexp hardcoded to avoid loading things
> like backups file an the like.
> So, yes, probably forcing to .nft is sensible.
I would go for glob support, ie.
include ./nft-ruleset-files/*.nft
so you can explicit indicate what file pattern you want to load.
prev parent reply other threads:[~2017-06-12 8:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 8:35 [PATCH 1/3] scanner: add files in include dirs in alphabetical order Ismo Puustinen
2017-06-07 8:35 ` [PATCH 2/3] man: add include directory documentation Ismo Puustinen
2017-06-07 10:09 ` Pablo Neira Ayuso
2017-06-07 8:35 ` [PATCH 3/3] tests: added tests for ordering files in include dirs Ismo Puustinen
2017-06-07 10:09 ` [PATCH 1/3] scanner: add files in include dirs in alphabetical order Pablo Neira Ayuso
2017-06-07 19:40 ` Arturo Borrero Gonzalez
2017-06-08 10:17 ` Pablo Neira Ayuso
2017-06-08 16:37 ` Arturo Borrero Gonzalez
2017-06-12 8:10 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170612081007.GA2462@salvia \
--to=pablo@netfilter.org \
--cc=arturo@debian.org \
--cc=ismo.puustinen@intel.com \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.