On 8 June 2017 at 12:17, Pablo Neira Ayuso <pa...@netfilter.org> wrote:
> On Wed, Jun 07, 2017 at 09:40:53PM +0200, Arturo Borrero Gonzalez wrote:
>> On 7 June 2017 at 10:35, Ismo Puustinen <ismo.puusti...@intel.com> wrote:
>> >
>> > +static int directoryfilter(const struct dirent *de)
>> > +{
>> > + if (strcmp(de->d_name, ".") == 0 ||
>> > + strcmp(de->d_name, "..") == 0)
>> > + return 0;
>> > +
>> > + /* Accept other filenames. If we want to enable filtering based on
>> > + * filename suffix (*.nft), this would be the place to do it.
>> > + */
>> > +
>>
>> This filter by suffix is good to have IMHO.
>> I guess that forcing users to explicitly create a file for nftables
>> (or at least give a specific suffix) reduces chances for user errors.
>
> You mean, this new include directory feature just takes *.nft files,
> right?
>
Yes,
> 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
