Required permissions to set Process.PriorityClass in Win 2003 serv

[Paul Roberts]

Hi All,

I have an asp.net application that needs to set it's priority to normal, but
I get access denied when the below code executes. The reason I have to do
this is I use a third party com component and it changes the priority to
high, so I want to bang it on the head to make it normal again.

System.Diagnostics.Process process =
System.Diagnostics.Process.GetCurrentProcess();
process.PriorityClass = System.Diagnostics.ProcessPriorityClass.Normal;

The code works just fine if the user has admin rights. I have also tried
giving the user 'Act as part of the OS' and 'Increase scheduling priority' in
local security settings and neither of these let it work. I should also
mention that this bit of code works just fine on 2000/XP without changing any
ASPNet permissions. To run on 2003 server I have also changed the
application to impersonate a new local machine account.

Does anyone know what permission the user needs to change the process
priority?

Cheers
Paul

 

[Nicole Calinoiu]

I have no problems setting the priority in this way on Windows 2003 when
code is running from within the (unmodified) default application pool under
the default NetworkService account. Are you receiving an exception or is
the attempted change simply not appearing to have the desired effect? If
the former, what is the exception?

 

[Nicole Calinoiu]

Paul,

If the user is a member of the built-in Users group, the only additional
privilege it should need is "Debug programs." However, as this is a rather
risky one to grant to real users, you should probably only do this if the
user in question in an account that is only used for the purpose of running
your application. Otherwise, you might want to consider temporarily
impersonating a user with this priviledge just for the purpose of altering
the process priority.

HTH,
Nicole

 

[Paul Roberts]

Hi Nicole,

I tried giving the user the 'Debug programs' privilege, but that didn't seem
to help at all.

I have now managed to make it work by changing the default aplication pool
to run as my new user account and adding the account to the IIS_WPG group. I
don't like this solution that much but at least it is now working. If anyone
else has any other ideas they would be appreciated.

Thanks for your help.

Cheers
Paul

 

[Nicole Calinoiu]

Paul,

Granting the debug programs privilege does work, but privileges are only
granted when a user token is first created, so you need to make sure that
you allow the token to be re-created before you test the change. One
sure-fire way is to reboot the server. Recycling the application pool is
not sufficient to pick up the changed token. (If rebooting isn't an option,
waiting a few minutes without any calls to the application will usually work
as well. However, I don't recommend this for testing since you won't know
if you waited long enough if a new call fails.)

That said, I still don't think that granting this additional privilege just
for the sake of changing the priority is necessarily a good idea.
Personally, I'd opt for running the application in its own pool even if the
security issue weren't a consideration since the other applications in the
default pool (or any other potential shared pool) should almost certainly
not be subjected to the priority switching in the first place. Is there any
reason you couldn't move the application into its own pool, configuring the
new pool to run in the context of your "special" account (or granting the
user debug programs privilege or impersonating a more privileged user just
to change the priority)?

Nicole