Issue #18045 has been reported by Nick Fagerlund.
----------------------------------------
Bug #18045: Remove all authorization rules from fileserver.conf (with
deprecation period)
https://projects.puppetlabs.com/issues/18045
Author: Nick Fagerlund
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
This came up when discussing the desired result of #17449 and #17448.
As plans for implementing this change, please edit the description.
## History
Fileserver.conf existed before auth.conf (...contemporaneously w/
namespaceauth.conf? Not clear to me whether those interacted), and it
implemented auth rules because there wasn't necessarily a better place for
them.
After auth.conf became the place for auth rules, we had two nested auth
systems, which was kind of deranged but mostly worked.
Then we broke fileserver.conf's auth rules while fixing an auth.conf bug
involving IP addresses.
## What to do
Nested auth systems are probably fundamentally bad; they're certainly not a
good match for our entangled auth code, where they cause inadvertent breakages
like this last one. Going forward, they'll limit our ability to improve things.
So **all** auth rules should probably just live in auth.conf. We should strip
all of the auth code out of fileserver.conf, so that it ONLY establishes mount
points.
[files]
path /etc/puppet/files
# Two lines per mount point, and that's all.
# Authenticated nodes can download files from this mount point.
# Use auth.conf if you need fine-grained access control.
## How to do that
Unfortunately, fileserver.conf mount points default to `deny *`, so we can't
just say "start acting like we already removed it." We'll have to make a
breaking change to default security behavior, which means a deprecation period.
### Eventual final behavior
* Fileserver.conf mountpoints all behave as though they had `allow *` and no
other auth rules.
* If there are **any** auth rules in fileserver.conf (w/ possible exception of
`allow *`), we throw an error and won't start the puppet master. The error
contains a suggestion for how to use auth.conf to granularly control access.
* Since this is a security behavior, we must fail hard immediately instead
of warning and continuing. We can't allow the perception that ignored auth
rules are working when they aren't; just because a user is unobservant doesn't
mean they deserve a security leak.
* If users need granular access control to custom mount points, they can
declare it in auth.conf.
* Auth.conf needs a redesign sometime real soon because it is generally
user-hostile, especially for this kind of access control:
* Anecdotal evidence from the monster thread about this indicates that
normal users need auth.conf's behavior explained about three times before they
start to understand ACL ordering and what constitutes a matching/non-matching
ACL. Pasting an ACL in the wrong place breaks everything.
* Furthermore, mount points do not map cleanly to REST API paths, since you
must control both the `file_metadata` and `file_content` endpoints.
* Furthermore, I have watched users get confused about where to use the
name of the mount point and where to use the on-disk path that the mount point
maps to.
### Intermediate behavior
* Fileserver.conf behavior stays the same as it is now; some auth rules work,
some break (but the breakages err on the side of overly-secure).
* We tell everyone to put `allow *` on their mount points and configure access
in auth.conf.
* We start emitting warnings whenever we see auth rules **other than** `allow
*` in fileserver.conf.
* We add a pref (false by default) to let you enable the final behavior (`allow
*` not required, fail hard if any auth rules are seen in fileserver.conf)
today. This will allow users to safely make sure they're ready for the next
version without fully upgrading, and it will let us make sure we got the
behavior right in the code.
* In the very next major version, we default it to true but leave it there.
In a minor version six months after that, we remove the pref and any dead code.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
