Link to home
Start Free TrialLog in
Avatar of John500
John500Flag for United States of America

asked on

Using FileIOPermissions

Greetings;

For the code below, where exactly would I declare FileIOPermissions and how would I use the 'FileIOPermissionAccess.AllAccess' approach?

Thanks
namespace MyNameSpace.FileOperations
{
    public class XMLFileOperations
    {
        private const string QPath = @"C:\TestDir\";
        private const string QFile = @"TestFile.Xml"; 
        private string path_ = null;
 
         FileIOPermission fileIOPerm1;        // NOW WHAT ??
  
        protected XMLFileOperations(string path)
        {
            path_ = path;
            queue_ = null;
            this.LoadXml();
        }
 
         private void LoadXml()
        {
            bool loaded = false;
 
            queue_ = new XmlDocument();
            try
            {
                queue_.Load(path_ + QFile);
                loaded = true;
            }
            ...
          }
    
         private void SaveXml()
        {
            queue_.Save(path_ + QFile);
        }
     }
}

Open in new window

Avatar of graye
graye
Flag of United States of America image

FileIOPermission is used to alter Code Access Security (CAS) settings for the assembly.
Is that what you want to do?, or are you trying to set "read/write" permissions to the file (like you do from the file's Properties/Security tab?
Avatar of John500

ASKER

Thanks for the input here.....

I'm not exactly sure what the problem is but this is the result:

Access to the path 'C:\TestDir\TestFile.Xml' is denied.

This application runs fine on XP and server 2003.  With our migration to 2008 the application now receives this error and shuts down.

If the problem was just due to file permissions, would the whole application be shut down?

I wouldn't mind addressing both possibilities (CAS & permissions) if you don't mind.

Thanks!
Avatar of John500

ASKER

... In addition to last post, consider the picture below showing all the possible methods used.  These are the results of right clicking on the 'Save' below and choosing 'Go To Definition':

queue_.Save(path_ + QFile);    //  Go To Definition on 'Save'

Would this suggest that .Net is the one restricting the access or Server 2008?



dot-Net-Save-methods.JPG
Avatar of John500

ASKER

Also, in addition to the access denied above, I get the same access denied for my own WriteToFile() method which writes from the same application:

Access to the path 'c:\TestFile.txt' is denied.

As I mentioned, all users are local admins when running this application and would have rights to save files to any directory ....

Hummm.....  
  • Where is the application located?   Is it installed on a client PC or do you run it from a network (share) location?
  • Is the server 32bit or 64bit
  • In the example you provided is "C:\TestDir\TestFile.Xml" relative to the client... or does that C:\TestDir directory live on the server?
Avatar of John500

ASKER

1)  The application runs on the server for anyone logging on whether they are on the machine physically or using a remote connection.  The idea is to log the task and time for using the machine (time is calculated automatically).  A modal dialog is launched forcing the user to identify their purpose on the machine.
2)  It's 64bit
3)  Both directories are located on the server.  The 'C:\'  location is not normally written to.  I  added a log routine to see if accessing the system was possible at all.  The original developer of this program used the System.xml.dll for the write routine that is being denied access.  I wanted to test a write operation with the typical System.IO routines.
There's no network share involved but as you may have figured, the Microsoft Messaging Queue is used to communicate when necessary.  I still haven't figured out why MSMQ is being used since the only queue action seems to be the xml file that's being blocked.
You can turn the 'journal' on to track messages used by the queue and I haven't seen any messages yet in about a month..............
Any ideas coming to mind?  Thanks!
Avatar of John500

ASKER

Regarding the network share, the whole system I guess would be considered a share.  I was wrong about physically sitting in front of the machine.  This system is a blade, therefore all access is done via remote desktop.............
If I'm following you, the application is only installed on the server... and the directories/files that are being written to are also on that same server
So, you don't launch the program from a client PC at all?
... the reason for all of these questions is to determine where the application is physically located and where it is actually running.  If the two are not the same (install location != run location), then we've got a potential CAS problem (that you solve at the "run location").
For example, at my place of work, we have a network share (called something like  \\server\share\programs) where we put all of our locally-developed applications.   We do not install them locally on the client PCs.  When a person wants to run one of the applications they merely connect to the network share (using a UNC style name or a mapped drive letter) and launch the application from that location.  In that case the "install location" does not equal the "run location"... and hence we need to adjust the CAS settings on the client PC.
The following is an article that explains a bit more about it:  http://home.hot.rr.com/graye/Articles/CodeAccessSecurity.htm
 
Avatar of John500

ASKER

>> So, you don't launch the program from a client PC at all?
Right, the application is located on the server and is kicked off during login because a shortcut to the executable is located in the Programs\Startup directory.
>> and the directories/files that are being written to are also on that same server
Yes, same server.  The only aspect of this that includes a client is the fact that users can't access the system without using remote desktop software.  The odd thing about this is, on XP and Server 2008 we haven't had a problem with acces.
Thanks again for the input
Avatar of John500

ASKER

... I ment with XP and Server 2003 .....
OK, then this is probably NOT a Code Access Security issue...   this is a Server 2008 (and Vista) directory permissions issue.  Recall that Vista/2008 have made some farily radical changes to what a "standard user" can have access to.   For example, users don't have write permission to the root of the C: drive, etc
So, tell  us more about the permissions of the directories.   I bet we can fix this with just a tweak to the NTFS file/directory permissions and not have to change your program at all.
Avatar of John500

ASKER

Ok terrific.

If I go to the folder which is being denied access and right-click, choose properties and then security, the user groups are (among others):

1) domain\Administrators (where 'domain' is the name of the company office)
2) domain\users

Believe it or not Administrators have full control, users do not... although I'm not concerned with users.

I noticed also that the 'Read Only' property of the folder in question is checked and partially grey. If I attempt to remove the check box, I can go through all the succeeding questions like - subfolders etc - but in the end, the check box never comes off. Also, I can save a file from notepad as an XML file to that directory with no problem.

Do these radical changes to Vista/2008 include granting application rights? However, I would think administrators could run any application they wanted.
Hang on.. if this runs during login, then it's being run with the credentials of the current user (which might not be a privileged account).   Recall that Vista/2008 uses User Account Control (UAC) to reduce an admin account to that of a "mere mortal".
To test this theory, change the permission on the directory/files so that an ordinary user can write to it.   If that works, then we're on the right track, and you can either turn off UAC or tweak the manifest of the application so that it doesn't require manual elevation.
BTW:  The grey box for "read only" is expected on directories, since it really only applies to files
Avatar of John500

ASKER

Well, that did it!  

So in other words, you are saying the directory called

Program Data\.....\Programs\Startup

... is run from the 'User' group no matter who the user is - including administrators?

Assuming the administrators who are higher than I don't like the idea of turning off UAC, can you tell me how to modify the manifest?

Thanks!

 
ASKER CERTIFIED SOLUTION
Avatar of graye
graye
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of John500

ASKER

Do appreciate the help and persistance !!  That's a load off.

I'll keep you posted on any question I open regarding the manifest if I need help... and if you should take interest.
Avatar of John500

ASKER

I figured I better post another question to make this process as painless as possible.  The instructions provided at the MSDN link (post 'ID:22914242')  are good.  Howerver, the only example applies to a C++ application.

Here's my new question if you get a minute:

https://www.experts-exchange.com/questions/23890984/How-to-configure-the-application-manifest-parameters-processorArchitecture-assemblyIdentity-version-uiAccess.html