To run code in an elevated context, you can use the method SPSecurity.RunWithElevatedPriveleges. Code run in the delegate (passed as a param) runs as the SHAREPOINT\system account when running in the SharePoint web application.  To run in the elevated context, however, you must create a new SPSite object which will run in the new security context, and you can create and manipulate objects obtained from that reference. I wrote about this here back in January of 2007.

What I've recently discovered is that SharePoint object model references created from the old SPSite security context (such as SPContext.Current.Site) MAY not be valid in the elevated context. We found a very obscure bug where an SPUser (SharePoint's security principal) pointed to anotehr user when the instance was called inside of the elevated context. This is a pretty obscure phenomenon, but the SPUser reference may point to another user when running in a different security context. To reliably manipulate the user's security, you must create a new instance of the SPUser object, which can be obtained by passing in the login name to the elevated code. This is  probably the most obscure bug I've came across, and one that is very difficult to track down.

For example, the following code is buggy because SPUser can identify the WRONG user when used in an alternate security context:

SPUser user = SPContext.Current.Web.CurrentUser;
SPSecurity.RunWithElevatedPrivileges(
  delegate()
  {
      using (SPSite elevatedSite = new SPSite(root.Site.ID))
      {
          using (SPWeb elevatedWeb = elevatedSite.OpenWeb(root.ID))
          {
              // This is bad-- the user cannot be reliably passed between contexts.
              SPRoleAssignment ownerRoleAssignment = new SPRoleAssignment(user);
              SPRoleDefinition fullControl = elevatedWeb.RoleDefinitions[@"Full Control"];
              ownerRoleAssignment.RoleDefinitionBindings.Add(fullControl);
              elevatedWeb.RoleAssignments.Add(ownerRoleAssignment);
          }
      }
  }
);

Here is the corrected code, which creates a new SPUser instance from the elevated context:

SPUser user = SPContext.Current.Web.CurrentUser;
SPSecurity.RunWithElevatedPrivileges(
  delegate()
  {
      using (SPSite elevatedSite = new SPSite(root.Site.ID))
      {
          using (SPWeb elevatedWeb = elevatedSite.OpenWeb(root.ID))
          {
              // You must always create a new SPUser instance to ensure the security principal is what you intend!
              SPUser elevatedContextUser = elevatedWeb.EnsureUser(user.LoginName);
              SPRoleAssignment ownerRoleAssignment = new SPRoleAssignment(elevatedContextUser);
              SPRoleDefinition fullControl = elevatedWeb.RoleDefinitions[@"Full Control"];
              ownerRoleAssignment.RoleDefinitionBindings.Add(fullControl);
              elevatedWeb.RoleAssignments.Add(ownerRoleAssignment);
          }
      }
  }
);

So the moral of the story: ALWAYS create new SharePoint object model references from within the new SPSite security context. Never assume that a reference created from the old security context (such as SPContext.Current) is valid in the new context. It may work most of the time, but not always. In my case, the bug was not reproducable in our CORP environment, but was  VERY reproducible in a specific customer environment.