How do I make a program that can onlybe run by an administrator

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I want to create a program that can only be run by a user with administrator
privileges (ie in the BUILTIN/Administrators group - I think. Correct me if
I'm wrong, I'm a bit hazy on users and groups). I'm not sure where to start.
Can someone point me in the right direction. I'm using VS2005 (just upgraded
from 2003)
 
Hello Dave,

just set only Administrator in the Security tab of the your app file property.
or google, as usual :) http://groups.google.com/group/micr...read/thread/376b1cdef6909aba/12ba8acd180775fe

D> I want to create a program that can only be run by a user with
D> administrator privileges (ie in the BUILTIN/Administrators group - I
D> think. Correct me if I'm wrong, I'm a bit hazy on users and groups).
D> I'm not sure where to start. Can someone point me in the right
D> direction. I'm using VS2005 (just upgraded from 2003)
D>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
 
Dave,

Try this.

WindowsPrincipal prin = new WindowsPrincipal(
WindowsIdentity.GetCurrent() );

if ( !prin.IsInRole( WindowsBuiltInRole.Administrator ) ) {
MessageBox.Show( "You're not an admin!" );
}

HTH
Andy
 
Andy said:
Dave,

Try this.

WindowsPrincipal prin = new WindowsPrincipal(
WindowsIdentity.GetCurrent() );

if ( !prin.IsInRole( WindowsBuiltInRole.Administrator ) ) {
MessageBox.Show( "You're not an admin!" );
}

HTH
Andy

The OP seems to have posted his question twice, and I wrote a response in
the other one about something like this.

Your code is very, _very_ nice. I like it, but the inherent flaw is, that
given this application, I could now disassemble it, remove the conditional
(or simply negate the expression) and reassemble it, thus giving me access
to the program.
 
Tom said:
Your code is very, _very_ nice. I like it, but the inherent flaw is, that
given this application, I could now disassemble it, remove the conditional
(or simply negate the expression) and reassemble it, thus giving me access
to the program.

Likewise, the user can change the security settings on the file (since
the user is likely an admin). This is much easier to do than decompile
a .Net program and remove the expression. Also, the program gets to
run and thus display a friendly message than 'Access is denied.'

Decompiling a .Net program is always a risk, regardless of what your
code is doing.
 
Andy said:
Likewise, the user can change the security settings on the file (since
the user is likely an admin). This is much easier to do than decompile
a .Net program and remove the expression. Also, the program gets to
run and thus display a friendly message than 'Access is denied.'

Decompiling a .Net program is always a risk, regardless of what your
code is doing.

Hi Andy,
Likewise, the user can change the security settings on the file (since
the user is likely an admin).

But if the measures are to prevent non-admins from executing the file, then
that's not an issue, as the non-admins shouldn't have permission to alter
the security settings on that file; and the admins should know better, than
to alter the permissions, if it's a sensitive application.
Also, the program gets to
run and thus display a friendly message than 'Access is denied.'

That is particularly sweet.
 
Hi Guys. Thanks for your replies. I posted twice because I was told I had an
error the first time. The UI on these message boards is DIRE - the link from
the notification email never works, the double click on a thread never works,
and quite often the whole message board doesn't work. And it tells you
there's an error and then posts anyway!
However, to the problem in hand - I can see both your points, however, if I
were going to follow Tom's advice and set the security permissions I would
want to do it as part of the installation - so how would I set that up with
the VS2005 installation pacckager.
Actually, what I would also really like to do is ensure that the app can
only be *installed* by an administrator - is that possible with VS2005?
 
Likewise, the user can change the security settings on the file (since
But if the measures are to prevent non-admins from executing the file, then
that's not an issue, as the non-admins shouldn't have permission to alter
the security settings on that file; and the admins should know better, than
to alter the permissions, if it's a sensitive application.

That is assuming the application is deployed in a business environment,
in which case you may be totally right (at my current employer,
everyone has admin rights to thier machine though.. I suspect we are
not alone.). The program in question could be a home user product,
which simply requires admin rights to do something. In that case, the
user likely can become the administrator, and more uses know of file
security settings than know how to decompile a .Net application, remove
the check, and then recompile it.

Just some things to consider. :-)

Andy
 
Dave, I would advise against going Tom's route (see my other reply
today), unless the application is an internal one for your business,
and normal users aren't admins of there boxes (in some companies, like
mine, they are.. no, they shouldn't be, but that's how it is).

However, if that's really the route you want (or if you need any other
custom actions during your installation, unrelated to this issue), what
you do is add an Installer class. The on the installer class you
create, override the install method. From that method, you can execute
CACLS to modfy the ACL. Or, if you're using .Net 2.0, you can use the
ACL classes within the .Net framework to change the permissions.

HTH
Andy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top