locked
Should file permissions of database be changed by compaction? RRS feed

  • Question

  • Background:

    Legacy application I’m working on allows users to compact a database associated with the application. Compaction is performed programmatically using this code:

    ::SQLConfigDataSource( NULL, ODBC_CONFIG_SYS_DSN,

    "Microsoft Access Driver (*.mdb)",

    “COMPACT_DB= C:\\Application\\Database\\MyDatabase.mdb C:\\ Application\\Database\\MyDatabase.mdb General” ) )

     

    Operating system Windows XP + SP3

    Application written in C++ and compiled using VS2005 w/ SP1.

     

    Problem:

    Compaction of the database file by any user not a member of the Administrator group will change permissions on the database. The changed permissions allow only administrators and the user who performed the compaction to access the database file.

     

    Additional Information:

    Normal permissions for this file are full control for the Everybody group in addition to the Administrators group.

    File permissions on the database file are returned to normal if the database is compacted by a member of the Administrators group.

    Previously, this app was run only by users belonging to Administrator group. Better security has mandated use by members without membership in the Administrators group.

    Thursday, September 29, 2011 12:03 PM

All replies

  • After more testing, it appears the check box for 'Inherit from parent the permissions...' on the tab 'Permissions' of the dialog box 'Advanced Security Settings for MyDatabase.mdb' is cleared by the compaction process when performed by a user. This same box is set by the compaction process when performed by an administrator.

    Thursday, September 29, 2011 5:07 PM
  • Compacting Access file resets NTFS permissions

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Thursday, September 29, 2011 7:48 PM
  • Thank you for the response. I read the article and tried the solution. It did not work for me.

     

    The article mentions ‘default NTFS permissions of the parent folder’. Are ‘default NTFS permissions’ different from those listed on the tab ‘Security’ in the dialog box ‘Properties’? If so, where are default permissions set for a folder?

     

    Also, the article lists Access 2000, Access 2002 and Office Access 2003 which are not installed on the machine in question. However, the machine does have version 4.00.6305.00 of the Microsoft Access Driver. I would guess Access 2000, 2002 and Office Access 2003 employ the driver to perform a compaction so perhaps this point is without merit here.

     

    I’m experiencing this same problem with another application using the same method to compact a different database. This other system is running on Windows 7 with service pack 1. This machine has Office Access 2003 installed but I don't think Office Access 2003 is the problem as I'm not using it to perform the compaction.

     

    Monday, October 3, 2011 8:02 PM
  • The default permissions depends on the operating system and local security policy. 

    From Procmon logs, at the end of compact/repair, a QuerySecurityFile call is made to get the DACL of the mdb file, presumably to get the permission set of the file in order to apply to the temporarily created compacted file. However this call appear to fail under your normal user context.

    If you can spin a process to a higher security context (e.g. a pre-launched service running as LocalSystem) you can adjust the permission after you finish compacting the database. I would change the permission to be inherited from the parent folder for easy management. The Jet engine you are using appears to use pre-Windows 2000 security APIs that does not support inheritance.

     



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Monday, October 3, 2011 10:49 PM
  • Thank you again for your response. I have done some additional testing and the results may be helpful. There are two systems experiencing the same problem. The first runs on Windows XP SP3 and the second Windows 7 SP1. Testing on the second system revealed Office Access 2003 can be used by any user to compact the database without changing permissions on the database file. The first system does not have Access of any version installed.

     

    Does Office Access 2003 perform compactions user privilege level or at an elevated level?

      

     

     

    Tuesday, October 4, 2011 9:06 PM
  • Jet is an in-process component. It uses the current process (MS Access or your app)'s security context.

    Windows Vista introduces "inherit only permission" that only apply to new children. It could be different from the permission of the folder itself. This is explained at the beginning of http://support.microsoft.com/kb/949608 and may be the reason of what you are seeing on Windows 7.

     

     



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Tuesday, October 4, 2011 9:49 PM
  • Thank you for your kind responses. Asking additional questions on this subject will not be fruitful for me at this time. I must do some research and testing to become better acquainted with this facet of Windows. I’m sure I will have additional questions and I will post them in a different thread.

     

    Links to articles, forum threads or site(s) about Windows security would be most appreciated.

    Thursday, October 6, 2011 4:54 PM