Click here to Skip to main content
15,892,072 members
Articles / Programming Languages / C#
Tip/Trick

Application Startup Permissions Validator

Rate me:
Please Sign up or sign in to vote.
1.25/5 (6 votes)
28 Mar 2013CPOL1 min read 76.6K   1.6K   46   4
This is a simple class/demo application that shows how to check whether the account that is being used to run the application has administrative rights.

Introduction

A few of the applications that we write and use may need administrative capabilities to perform and complete the requests. To install the application we can ensure to have it wrapped into a Windows Installer (MSI) shell so that this requirement is taken care of. But how would we deal the same with respect to day to day use of the executable? 

Solution

This quick utility demonstrates two perspectives of dealing with this issue:

  1. Having an Application Manifest that stipulates the need for administrative access.
  2. Having  an Assert Permission Demand as a pre-requisite for the application to run.
  3. A quick manual check as a first step in the application. 

App Manifest  

For the project that you want to add 'Require Administrative' access, add an App.manifest file with the following directive amended:

XML
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Permission Demand:

The constructor of the class which needs elevated permission should read as

XML
[SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.AllFlags)]

Additionally, I am doing a quick check WindowsPrincipal of the logged on user and whether he is part of administrator. 

 Please note that the first step of App.Manifest would trigger the UAC alert if enabled. If UAC is disabled then there is a most likely chance that this step can be bypassed. However then our contingency checks in (2) and (3) can chip and help us out.

Summarizing: 

This brief tip/article has the following objectives to convey to a beginner .NET developer to focus on robust applications that conform to Windows Security and responsive enough to user permission requirements.  

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer
India India
Vasudevan Deepak Kumar is from Chennai, India who has been in the programming career since 1994, when he was 15 years old. He has his Bachelors of Engineering (in Computer Science and Engineering) from Vellore Engineering College. He also has a MBA in Systems from Alagappa University, Karaikudi, India.
He started his programming career with GWBasic and then in his college was involved in developing programs in Fortran, Cobol, C++. He has been developing in Microsoft technologies like ASP, SQLServer 2000.
His current focus is ASP.NET, C#, VB.NET, PHP, SQL Server and MySQL. In his past-time, he listens to polite Carnatic Music. But the big question is that with his current Todolist backlog, does he get some past time?

Comments and Discussions

 
GeneralNice Demo Pin
Gevik Babakhani25-Nov-02 13:10
Gevik Babakhani25-Nov-02 13:10 
QuestionWhy not? Pin
Matthew Adams25-Nov-02 4:28
professionalMatthew Adams25-Nov-02 4:28 
AnswerRe: Why not? Pin
Vasudevan Deepak Kumar25-Nov-02 4:33
Vasudevan Deepak Kumar25-Nov-02 4:33 
GeneralRe: Why not? Pin
Matthew Adams25-Nov-02 5:03
professionalMatthew Adams25-Nov-02 5:03 
I agree; if you have a bunch of business logic that needs to be grouped together atomically, then using the principal.IsInRole() stuff is certainly one way of dealing with it (without throwing exceptions).

Personally, I prefer to use the PrincipalPermission.Demand() in the constructor of my business object, and then catch the SecurityException(s) in the layer that creates the business object.

This has the advantage that a) the security demands are encapsulated in the business logic, rather than the client of that business logic and b) you have a unified mechanism for handling security exceptions thrown by both your business logic, and any dependent business logic.

Another advantage of this approach is that you do not depend on creating a Windows security principal (as you do here). Your application could create a custom security principal, and add roles as appropriate.

Another option is to use declarative security (adding attributes to your methods with the appropriate Demands), but I find this somewhat inflexible.

On the exception handling front - yes, I agree, you should always design your layered exception handling schemes (whether security-related or otherwise) with the transactional model of your system in mind. For example, what happens if your app needs to make some changes to the database, send an email to person A and another email to person B, then do some more database updates, before you consider the transaction to be complete? What if the email to person A succeeds, but person B fails, or the second db update fails? This is a (typical, but) difficult problem, which is more in the realms of business process analysis than abstract transactional models.

As another 'what if' example on this front, what if my local security settings do not allow me to execute particular operations in your business logic (say you have something which accesses my local hard disk, but my permissions do not permit this) - you still need to cope with that configuration reliably, and that *still* means designing an appropriate layered exception handling scheme if you are not to crash and burn (part way through a transaction!)

M

Matthew Adams
Development Manager
Digital Healthcare Ltd

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.