views:

1033

answers:

2

From what I have gleaned from reflector, RunWithElevatedPriveleges simply reverts the current thread identity to the base (non-impersonated) identity. This makes perfect sense in the case of code running inside the WSS application pool, since the base service account is a super-user. Does it have any effect when running in an external (console or service) application, when no impersonation exists? I'm guessing not, but I'd like to know for sure. I've seen varying opinions on this from googling.

+3  A: 

I think it would if you ran the executable under one account and then changed it's credentials with code (like SP does). Otherwise, it cannot elevate to permissions it didn't have at start without some way of generating a Credentials object.

Lou Franco
+3  A: 

Normally Runwithelevatedprivileges will get your code running as the app pool identity, but it doesn't work from the console. What we've done in this case is either use runas or a set the identity of a scheduled task to the same account as the app pool identity.

Eugene Katz