Bug #3131
Cannot restrict access to single module in fileserver.conf
| Status: | Accepted | Start date: | 01/30/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | modules | |||
| Target version: | 2.7.x | |||
| Affected Puppet version: | 0.24.8 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
My fileserver.conf looks like:
[modulename]
/etc/puppet/modules/modulename
allow x.x.x.x
[modules]
allow y.y.y.y/23
I want to restrict access to modulename to just the one server that needs it, x.x.x.x, such that all the other servers that do not require access to the module contents, especially the files, are prevented from fetching them.
However, this currently does not work properly at all. A server on another ip still has full access to the module’s contents.
Possibly this is because it’s still getting in through the [modules] section after failing the [modulename] section I don’t know. If so it might be a very simple fix to simply stop at the first match.
History
Updated by James Turnbull about 2 years ago
- Category set to modules
- Status changed from Unreviewed to Needs Decision
- Assignee set to Luke Kanies
- Target version changed from 0.25.5 to 2.7.x
Updated by Luke Kanies about 2 years ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
Luke Kanies)
How should this work? I don’t think module-specific headings make sense; I’d prefer something like:
[modules/modulename] ...
Or something similar, so it’s clear you’re affecting a specific module.
Or is there a better syntax?
Updated by Hari Sekhon about 2 years ago
I was thinking in terms of code it might be simpler to just stop evaluation at the first match, as one does in firewall rules… so there is already precedent for this type of behaviour.
However, I think your way is better since it could be agnostic of position in the configuration file and does seem more explicit, rather than confusing regular file mounts from modular ones.
I don’t mind how it’s done, as long as I can override access controls on a module by module basis.