I could be waaaaaay off, but...

It seems that a model is necessary to use the library, you just don't care which one, right? Further, the library doesn't care how the model gets its data, or where the data comes from, it just wants an object that meets the criteria of the interface.

If the library doesn't need the connection object, then make that the responsibility of the model.

interface MyFooModelInterface 
{
    public function getItem($id);
    public function addItem($item);
    ...
}

And here is a simple class example:

class MyLib
{
    protected $model;

    public function __construct(MyFooModelInterface $model)
    {
        $this->model = $model;
    }

    public function getItemById($id)
    {
        return $this->model->getItem($id);
    }
}

And a Model example:

class MyModel implements MyFooModelInterface
{
    protected $conn;

    public function __construct(\PDO $conn)
    {
         $this->conn = $conn;
    }

    public function getItem($id)
    {
        ...
    }
    public function addItem($item)
    {
        ...
    }
}

And here is an example of using it:

// the model is responsible for handling the data retrieval, not the library
$model = new Model($conn);

$lib = new MyLib($model);
return $lib->getItem($id);

Now, if I decide that I want a file-based solution, I can easily swap the model. To test the model, the connection obj is injected, so that's easy. To test the library, the model is also injected, so, again, that's easy.

In this case, the model is only responsible for getting the data, while the library is responsible for handling and processing the data. Neither cares what or how the other one does it.

EDIT

the library with a factory method to create the model if none was given...

class MyLib
{
    protected $model;

    public function __construct(MyFooModelInterface $model = null, $conn = null)
    {
        // if we have a model, use it
        if (!is_null($model)) { 
            $this->model = $model; 
        }

        // if we don't have a model, but have a connection obj, make a model
        if (is_null($model) && !is_null($conn)) { 
            $this->model = $this->factoryModel($conn); 
        }

        // if we don't have either, quit and go home
        if (is_null($model) && is_null($conn)) {
            throw new Exception('need moar inputs');
        }
    }

    protected factoryModel($conn)
    {
        $this->model = new MyModel($conn);
    }

    public function getItemById($id)
    {
        return $this->model->getItem($id);
    }
}

Your understanding is correct. Keep in mind that different frameworks use different approaches, so something which would for instance apply to Laravel won't necessarily apply to, say, Symfony.

This is especially true when it comes to deciding where the logic goes: some frameworks use models as basic objects containing data, but practically no logic by themselves. Other frameworks encourage you to move some logic from the controllers to the models.

A few comments:

• Why is your controller called index.php? Usually, the application has several controllers with the names which indicate their purpose. For instance, an e-commerce website can have a products.php file which contains the controller logic handling http://example.com/products/... requests, customers.php file for customer-related stuff, cart.php for you guess what, etc.

  Unless you have separate directories for each of them, such as /products/index.php, customers/index.php and cart/index.php, you are putting all the logic in the same file. As a consequence, even if the file is currently small, it will grow through time, and become very difficult to maintain.

• While doing input validation inside a controller is a perfectly valid approach, some frameworks move the validation logic from the controller to (1) the model and (2) the framework itself. I don't know PHP frameworks, so I'll give an example of ASP.NET MVC: usually, properties within the models have specific attributes which indicate how should they be validated. Then, basic validation logic is applied by the framework itself during the mapping.