1. The user id 1 account ("user/1"), sometimes called "superadmin" is able to do everything on a Drupal site. Drupal access checks will always allow this account to take an action. Another special permission is that user/1 is the only user that can execute the update script (example.com/update.php).

    User/1 is the only account that has permanent/non-removable access to everything based on the account itself. Any other user can have permissions added or deleted as their status changes with the site. This can never be done to user/1. Due to the permanent nature of these permissions, some people feel it is not appropriate to use this account for "day to day" purposes for a few reasons:

    • If user/1 is creating content in addition to holding superadmin privileges, that content will need to be transferred to another user account if user/1 needs to be passed to another person. Changing content attribution from one account to another is not trivial. If the original user/1 will also be the author of content, it is considered a best practice for that person to create a different account in order to submit content.
    • If you use this account on an insecure computer or on an insecure network a malicious user could steal your login and get full access to your site. However, if you use a secondary user that has "Administer users" access then this problem is still real regardless of the uid of your user. So, the advice here is simply to only login when you are sure about your network OR to use https to login. If you don't want to buy a certificate, the OpenID system allows you to login via https to your OpenID server while still gaining access to your Drupal account.
    • There is a possibility of a module having a XSRF or a "GET" URL which takes an action. If you are logged in as a user with the permissions to take that action and then a malicious user sends you a specially constructed email or IM which takes advantage of that security hole on your site then your site could be compromised (this is a pretty unlikely scenario for most people).
    • Some site developers may use the user/1 account for a site and then hand over that account to their relatively inexperienced site admin user when the site is launched. Instead, an inexperienced site admin should be given a new account that is a member of a role that has the permissions appropriate to their level of expertise.
  2. Set up some appropriate roles (do not forget to update these roles as you add new modules). Some role suggestions are 'site admin', 'user admin', 'site contributor'. What roles you need to create will depend on the type of site you have designed. Note that anyone who can administer users can grant themselves additional permissions.
  3. Adding new modules often adds additional permissions options. When adding new modules revisit your access lists to check for appropriate access for your roles.