At least once in his career, a SharePoint developer is going to be faced with a security problem.

When a user executes an action in SharePoint, i.e. modifies an item in a list, the request on the server executes using the security context of the user. So, if the user does not have the right privileges to accomplish specific actions, the request could fail with a security exception.

A way to overcome this behaviour is to use the RunWithElevatedPrivileges method from the SPUtility class.

An important thing to keep in mind when using this method is the initial context of the object on which you will execute specific actions.

In the example below, even if you use the RunWithElevatedPrivileges method, the security context of the SPWeb object (web variable) is inherited from the user permissions.
This behaviour is normal because the SPSite site variable is a reference to the properties variable which was created with the user’s security context.

public override void ItemUpdated(SPItemEventProperties properties)
{
	SPSecurity.RunWithElevatedPrivileges(delegate(){
		using (SPSite site = properties.ListItem.Web.Site)
		{
			using (SPWeb web = site.RootWeb)
			{
				web.AllowUnsafeUpdates = true;
                                // Do some actions
			}
		}
	});
}

To run in a context with full control, all objects should be instantiated inside the RunWithElevatedPrivileges delegate method.
By doing this, objects will inherit their permission from the RunWithElevatedPrivileges context which is full control:

public override void ItemUpdated(SPItemEventProperties properties)
{
	SPSecurity.RunWithElevatedPrivileges(delegate(){
		using (SPSite site = new SPSite(properties.ListItem.Web.Site.ID))
		{
			using (SPWeb web = site.RootWeb)
			{
				web.AllowUnsafeUpdates = true;
                                // Do some actions
			}
		}
	});
}

Here is the exception I encountered:

Unexpected end of file while parsing Name has occurred. Line 1, position 708. System.Xml.XmlException: Unexpected end of file while parsing Name has occurred. Line 1, position 708.[...]

After a lot of searches on the Internet, I’d found a very helpful post on the InfoPathDev forums.

To summarise, if the server on which you’re developing is running with Windows SharePoint Services SP1 (Service Pack 1), your InfoPath form must not have a useless secondary Data Connection (declared but not used at all on your form).

Very simple… if you know it!