IMHO it depends on a number of things. Using groups and memberships is good if the flags are meant to indicate an ability to do something on the system because there are decorators and functions to test for having the attribute. You can then decorate a function or use a has_.... test to determine ability in the code.
If all you want to do is test something in code and there are a fixed and small number of these flags then an extension to the user table might be the easiest using a binary column per flag type. One problem is a new flag causes a schema change. It would be the most efficient, reading the user table could pull these in at the same time but that would be premature optimization. The relations in the auth_* tables look like this in ascii auth_user -----> auth_membership <------ auth_group ----> auth_permission where ----> indicates a one to many relation. Therefore auth_membership is an intermediate or join table that realizes the many to many between auth_user and auth_group. The auth_permission table can be used to hold capabilities and not be associated with tables at all by means of a settings tweak. Then a permission can be assigned to only one group but a group can have several permissions. Then users can be assigned to multiple groups to collect the capabilities assigned by the admin. By using the group you can lump several flags that belong together. This works for me to define a hierarchy of users for the application I am working on. I am able to customize the permission items to whatever group type the installation needs to allow or disallow a group to have a certain capability without having to change what groups the users belong to, something like a policy editor as in this group can do these things. If all the flags are single purpose and are not grouped then I would think you could collapse this to a flag = group item. I am not certain of lists in columns. It is used with GAE to get around the lack of functionality in their DB but many db admins call it an anti-pattern called jay walking. The main difficulty is searching for a particular attribute in the list from a SQL perspective.
