Issue #18045 has been updated by eric sorenson. Status changed from Needs Decision to Accepted Assignee changed from eric sorenson to Andrew Parker
The work for 3.1 should just be the steps Nick outlined under the "intermediate behavior" section. ---------------------------------------- Bug #18045: Remove all authorization rules from fileserver.conf (with deprecation period) https://projects.puppetlabs.com/issues/18045#change-78846 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Andrew Parker 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.