This is a bit of a messed up situation unless the admin's posts are supposed to be public.
Anyway, permission or privilege systems can be really simple or quite complex depending on your needs. A simple system would have an 'is_admin' field in the DB so that when a user logs in s/he immediately has or does not have admin rights. You can store the is_admin value (usually set to 1 or 0 as a tinyint datatype) in a session variable, e.g.
As this is a little verbose to be using throughout your code, you may wish to store it in a global constant - (although this is not strictly how constants arre meant to be used I suppose):
or similar in a configuration file. You then use it as:
This has the advantage of being able to be accessed throughout your code, as oposed to storing it in a simple variable (e.g. $is_admin) - although the session variable is also 'superglobal'.
However, if you wish to ascribe different permissions to different roles and create a number of different roles, each having a different set of permissions, e.g. SUPERADMIN, ADMIN, MODERATOR, CUSTOMER, then you need to dig a little deeper.
You could still keep the relatively simple table structure, but slightly altered, so you could use "user_level" instead of "is_admin" and give each a tiny integer (e.g. 1-4).
If the permissions are cumulative without exception (i.e. MOD has all permissions of CUSTOMER and a few others, ADMIN has all permissions of MOD plus a few others, SUPERADMIN - well has all permissions), then you can use a < and > to gauge whether a user may perform/view something.
if(USER_LEVEL > 1)...
Would allow Mods, Admins and Superadmins but NOT Customers to do something.
If permissions are not cumulative, then you could have values that exploit bitwise operators. So you could store your userlevels thus:
SUPERADMIN = 8, ADMIN=4, MODERATOR=2, CUSTOMER=1
Or actually, any order would work for this. Now you could use this:
if(USER_LEVEL & 6)...
That would allow ADMINs (4) and MODs (2) but NOT CUSTOMERS (1) and SUPERADMINs (8). Unfortunately, that doesn't make too much sense with regard to this example, but you could have different flavours of customer or mod which would benefit from this type of flexibility.
That takes the sting out of making the DB more complicated, BUT it does place restrictions on your code. If you add new user_levels, you will have to change your hard-coded bitwise values. PITA.
So for a more mature setup, you may find creating a separate role and permissions tables. But that's for another discussion.
There are many, many ways to implement this. Just a few ideas. Rambling again...