overall code organization: helper, library, core, or model?

For #7, it really depends on how you are doing authentication.  I like to do it in a controller constructor hook, some might do it in a MY_Controller that they extend, or you could write a custom validation rule.  You could add a hasBidAccess function to your authentication library that calls a function in a datamodel that does a query.   There are a lot of options.
 

I'm sort of torn here. It certainly seems clear that a given page view or action should be intercepted by a controller if a user is not sufficiently privileged. Viewing admin dashboard, for instance, should not be accessible except by admin. On the other hand, other actions may depend on a lot of conditions that seem squarely in the Model camp: existence of records in a particular database, values from a database, etc. The rules for access to a particular action could be quite elaborate. I've heard discussion of using Interceptor Pattern in this context, but can't yet formulate a proper vision of code and data structures. In particular, creating three base controller classes:
* Public - for pages accessible to everyone
* User - for pages accessible to registered users
* Admin - for pages only accessible to Admins.
This might work fine for a simple site but what if you want to specify a-la-carte permissions like an ACL or *nix-style file permissions? Or what if you have N user levels rather than just these 3? I'd appreciate any thoughts on code structures, data structures, and code organization if anyone has any.

In Bonfire, our Base_Controller includes a boolean $require_authentication property which determines whether the user is required to authenticate to view the pages loaded by that controller (by default it is false in the Base_Controller). If the property is set to true, the auth library is loaded and the user is prompted to log in to view the page. Our Authenticated_Controller defaults the property to true and changes a few other options, but doesn't really contain much additional functionality. Our Admin_Controller does some additional configuration beyond that (like setting a different theme for the template library), but again doesn't include much in the way of additional functionality.

Our auth library, on the other hand, has a method called restrict(). When called with no arguments, it just requires the user to log in. If the name of a permission is passed to auth->restrict(), the user has to have that permission to continue execution to view the page. This allows us to set the permission requirements on a per-controller basis (in the constructor) or in individual methods in the controller.

It would be fairly easy to extend the basic idea to allow configuration of the permissions required for each controller/method, load the configuration in the controller's constructor, then apply those permission requirements (though off the top of my head the method-level requirements may be a little more difficult than the controller-level requirements).

We can also use auth->has_permission() to do finer-grained control, perhaps allowing the user to see the page but changing what is displayed.

I wouldn't hold up Bonfire's auth library as a perfect code example, as I feel it's a little too entangled with Bonfire's template library and its user, permission, and role models, but at a surface level for discussion of how authorization can be handled in an application it works fairly well.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide