Rather than extending your User class, you should wrap your User class inside a SecureContainer. See the linked-to answer for details, but then the overall call would be:

// assuming that you have two objects already: $currentUser and $controller
$acl = new AccessControlList( $currentUser );
$controller = new SecureContainer( $controller, $acl );
// you can execute all the methods you had in previous controller
// only now they will be checked against ACL
$controller->actionIndex();

This allows the User class to focus on what it needs to do, and allows the AccessControlList class to focus on what it needs to do.

Not necessarily. A class should have only one reason to change. You can have these methods in a domain object and delegate the logic to other classes, injected into the domain object.
–
pdrApr 10 '13 at 13:05

if the permission is in some sense a property of the user, that's the natural place for it to store the data

if the permission is a property of the list, that's the natural place to store it

if the test for permission is naturally an action on the user (ie, that syntax fits best with your usage pattern), that's the natural place to put the method

if the list shouldn't know about the user, and the user shouldn't know about the list, but some separate ACL should know about both and their relationships, maybe that is where the data and/or method should go

etc. etc.

In general, there seem to be three separate (or separable) concerns: describing a User, storing a List, and managing the Access of one to the other.

If you choose to combine two of those concerns into the same class (and if so, which), it should either be because this arrangement emerges naturally from your model (... is a property of ...), or because it's more convenient or efficient. You haven't told us enough to make that choice for you.