Solved

System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. Trying to set permissions on a file

Posted on 2009-07-13
2
3,771 Views
Last Modified: 2012-08-13
I have an app that uploads files into a unc directory that everyone has permission to upload to.

 

The interface uses a proxy webservice that call another webservice. (this is done for security purposes and works fine in all otehr instances) he proxy webservice runs as a speciifc useraccoutn that gets verified on the end point webservice);

Once the file is their the application calls the proxy webservice(which calls the webservice that controls this upload direttory) and removes the inherited permissions and applies specific permission to the file so that it can no longer be accessed by a specific usergroup.

This second webservice also runs under a specific system acount that has full control to the directory in question.

The webservice webmethod  uses impersonation initially to verify that the call is coming from the parent webservice but once that occurs it stops impersonating so that it can run as the service accoutn that controls the directory. (app pool is configured to run under this account)

But for some reason I can not figure out despite it being explicityly told to STOP impersonating (which defacto should cause it to run as its app pool account) UNless someone with local admin rights on the web server runs the command from the interface it returns the error

 

System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)

at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)

at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections, Object exceptionContext)

at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections)

at System.Security.AccessControl.FileSystemSecurity.Persist(String fullPath)

at System.IO.File.SetAccessControl(String path, FileSecurity fileSecurity)

at System.IO.FileInfo.SetAccessControl(FileSecurity fileSecurity)

at omnifrmwk.InternalClasses.FilePermsMethods.RemoveInheritablePermissons(String FileName)

 

 

Add the user to the local admin group and it works fine.

Remove the user from the local admin group and it gives the error...

BUt who the user is shouldnt matter at all by that time it has stopped impersonating the original caller TWO service gone and should be impersonating the username of the app pool. Even stranger...when it works because the original caller has admin rights and applies the permission correctly..the permissions applied are generated by the account that the method is running as..so I can see what account is actually setting the permission (since it set the permissions for itself) and it is the correct service account...so I have NO IDEA why it should matter at all whether the user on teh inetrface end has local admin rights or not on the web server running this third tier web service.

 below is the code I use which you can see expliciltly says to stop impersonating...

WindowsImpersonationContext ctx = WindowsIdentity.Impersonate(IntPtr.Zero);

            

            try

            {

               //get the username of the currently running acount
 

                string ealmsAccount = omnibll.UserAuth. GetUsername ();

                omnifrmwk.InternalClasses.FilePermsMethods.RemoveInheritablePermissons(file);

                omnifrmwk.InternalClasses.FilePermsMethods.addFullAccess(file, ealmsAccount);

                
 

                succ = true;

            }

            finally

            {

                ctx.Undo();

            }

}

Open in new window

0
Comment
Question by:Prysson
2 Comments
 
LVL 41

Expert Comment

by:graye
ID: 24858951
0
 

Accepted Solution

by:
Prysson earned 0 total points
ID: 25026010
The problem was one of ownership...issue resolved.
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Just a quick little trick I learned recently.  Now that I'm using jQuery with abandon in my asp.net applications, I have grown tired of the following syntax:      (CODE) I suppose it just offends my sense of decency to put inline VBScript on a…
User art_snob (http://www.experts-exchange.com/M_6114203.html) encountered strange behavior of Android Web browser on his Mobile Web site. It took a while to find the true cause. It happens so, that the Android Web browser (at least up to OS ver. 2.…
Along with being a a promotional video for my three-day Annielytics Dashboard Seminor, this Micro Tutorial is an intro to Google Analytics API data.
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…

863 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now