Maybe we can also hardcode the alias rm='rm -i', just in case.
Your intentions are nice, but that are too much lines for a naive test
that a serious 'root' would have hit with a simple -and mandatory-
'pfctl -s rules'.
El 02/01/2012 18:59, Stephane A. Sezer escribis:
On Mon, 2 Jan 2012 15:28:48 -0200
"Christiano F. Haesbaert"<haesba...@haesbaert.org> wrote:
On 2 January 2012 06:58, Henning Brauer<lists-openbsdt...@bsws.de> wrote:
what next? having pfctl whine about an empty config file?
* Stephane A. Sezer<s...@cd80.net> [2012-01-02 09:36]:
Hi,
I found a strange behavior in pfctl(8) which looks like a bug.
When given a directory as input (either with the `-f` flag, or with the
`include` directive in a config file), pfctl(8) does not emit any
warning and silently accepts the given input.
I suppose this is not the intended behavior so here is a patch that
fixes the issue.
Even if it is the case, testing against directory doesn't seem like
the right thing, the test should be done against a regular file, what
if you pass a block device ? another check ?
I thought it would be valid (for some obscure use cases) to give
pfctl(8) a named pipe, or an unix socket as input. Giving a block
device or a char device already triggers a warning in most cases but
yeah, it makes sense to check them explicitly too.
You're only dealing with a very special case here, anyway, I agree
with Henning, it seems too much.
Lots of config files formats accept the syntax
include "/some/directory"
telling the program to include every single file in `/some/directory`.
pfctl(8) doesn't. And doesn't even warn about that.
Personally, I came across this behavior with a failed tab-completion on
`pfctl -f /etc`.
