Depends on what you mean by business logic. Any "logic" that gives meaning to contents of the model should be in the model. In the linked question, the highest voted answer seems to define "business logic" as anything relating to data; this makes sense from the point of view that a business' data is its business!
I once saw an example by the creator of Rails (I think) who was going on about exactly this - not putting "business logic" in the model. His example was a controller class and method for app registration and login - a supplied password in plaintext was encrypted before being inserted into or queried against the model (a database.)
I can't think of a better example of something that is not controller logic and that belongs directly in the model.
The model could be an interface to myriad data stores, alleviating portability concerns. It's here one could find confusion over wether or not the model interface is actually the "controller."
Generally speaking, the controller links the model and view (which are the meat-and-potatoes of the app.) In Cocoa development it can be simplistic to the point where the controller is handled via the XCode GUI (controller objects and bindings.)
The GoF's "Design Patterns" section on MVC, loosely quoted:
The MVC triad of classes is used to build user interfaces in Smalltalk-80. The Model
is the application object, the View is its screen presentation, and the Controller defines
the way the UI reacts to user input. MVC decouples views and models by establishing a
subscribe/notify protocol between them. The following diagram shows a model and three
views. We've left out the controllers for simplicity.
MVC is all about UIs. The focus is on the model and view - defining and displaying data. Note the "subscribe/notify protocol" - this is where your controller comes in. You can build all the views you want; so long as they adhere to the protocol you'll never have to touch the model or controller.
If you're talking web development specifically, IMHO many popular web frameworks are fast and loose with the term MVC and its component definitions.