The method you described -- individual privileges stored in columns -- is straightforward at the expense of flexibility (as you noticed).
Zuul's method is even more simple and essentially the same as yours, except it avoids the need for any "ALTER TABLE" statements. However, it is not normalized, not easily queryable and not self-documenting.
Another problem with both of these methods is that as your user base grows, you will find it increasingly more of a pain to keep everybody's privileges set properly. You will find yourself with a lot of users who need exactly the same privileges. Yet in order to change a user's privileges, such as to accomodate a new privilege, you will have to go in and add that privilege to each user who needs it individually. Major PITA.
For a forum, it's not likely that you'll need per-user privilege management. More likely you'll have certain classes of users like anonymous users, logged-in users, moderators, administrators, etc. This would make it well-suited for role-based access control (RBAC). In this system you would assign each user to a role, and grant privileges to the role. Privileges would be stored as rows in a "privilege" table. so the simplified database schema would look like:
PRIVILEGE
int id (primary key)
varchar description
ROLE_PRIVILEGE_JOIN
privilege_id (foreign key)
role_id (foreign key)
ROLE
int id (primary key)
varchar description
USER
int id (primary key)
int role_id (foreign key)
This pattern is used in many applications that deal with user privileges. Add every privilege that anyone could possibly have as a row in the privilege table; add every role that any user could possibly have in the role table; and link them appropriately in the role_privilege_join table.
The only real disadvantage is that because a join table is used, the "can user X do Y" query is going to be somewhat slower.