Puppet

This would be a significant behaviour change; the present assumption is that modules and plugins are accessable by default.

Markus Roberts wrote:

This would be a significant behaviour change; the present assumption is that modules and plugins are accessable by default.

Then there’s some kind of documentation error, or at least confusion.

Note that at http://reductivelabs.com/trac/puppet/wiki/FileServingConfiguration it says “The default security configuration is to deny all access, so if no allow lines are specified, the module will be configured but available to no one.”. That sounds like “deny all is the default” to me.

Furthermore:

1. If I put anything in the [modules] section, “deny all” is suddenly the default behaviour; everything I haven’t explicitly allowed is denied. This strongly implies that “deny all” is the default state.

2. “allow ” is OK, but “deny ” is a syntax error. This also, very strongly, implies that “deny all” is the default state.

The problem is that when the [modules] section is entirely empty, the behaviour shifts from “deny all” to “allow all”, which is very confusing. If the section missing did that, that would be (mildly) less confusing, but having an empty section do that when the documentation makes it clear that “deny all” is the default is very confusing.

Even then, I would be fine with it if “deny *” worked; all I was trying to do was test that in the “deny all” state, nothing worked.

With the current setup, it is impossible to actually put the config into a “deny all” state; the best you can do is allow something insignificant (or impossible, like a non-routable address not on your network). That’s icky.

-Robin

I agree, this is a bug.

Is it sufficient to just allow a ‘deny *’ statement in the configuration? That is to say, are the current defaults acceptable, as long as that additional setting is available?

That would absolutely be OK by me, yes. Thanks!

-Robin