Issue: When ALTER TABLE is executed, certain inherited permissions to the .dat and .idx
are lost. This can cause a user to lose access to their data.


(full, nicely formatted problem report attached as txt - thank you!)


Background: On Vista and Windows7, we have observed that users can lose access to data
that is stored in a public folder on their PC. We determined that this is happening
because when an ALTER TABLE command is done, DBISAM seems to recreate the .dat and .idx
files. The newly created .dat and .idx files are not getting all the folder permissions
assigned. If the user is a "normal" windows user (e.g. not an administrator), and the
ALTER TABLE is done as any other user on the PC, the user will lose write access to the
.dat and .idx files.


The problem is very quick and easy to reproduce. I am doing these steps on a Windows7 x64
system, however I believe the issue applies to all Vista and Windows7, x86 and x64.


STEPS to reproduce:

1) You need two users: admin and joe. Joe is a normal user, not an admin equiv.

2) As administrator, execute a CREATE TABLE operation to put a DBISAM table in
  a directory under the public document directory.
  E.g. Under:  C:\users\public\documents\
  Specifically, for this test, create this dir: C:\users\public\documents\dbisamtest\
  
  CREATE TABLE mytesttable
  (First_Name char(50),
  Last_Name char(50))
     
3) Confirm that user joe has full read/write access to this table.

4) As joe, go to a command prompt in the \dbisamtest\ directory and run this windows command
  to see the ACL of the file:
  
   icacls mytesttable.*
   
5) Note the results:

       icacls mytesttable.*
       mytesttable.dat BUILTIN\Administrators)(F)
                       Win7x64\joe)(F)
                       NT AUTHORITY\SYSTEM)(F)
                       NT AUTHORITY\INTERACTIVE)(M,DC)
                       NT AUTHORITY\SERVICE)(M,DC)
                       NT AUTHORITY\BATCH)(M,DC)

       mytesttable.idx BUILTIN\Administrators)(F)
                       Win7x64\joe)(F)
                       NT AUTHORITY\SYSTEM)(F)
                       NT AUTHORITY\INTERACTIVE)(M,DC)
                       NT AUTHORITY\SERVICE)(M,DC)
                       NT AUTHORITY\BATCH)(M,DC)

       Successfully processed 2 files; Failed processing 0 files    
       
6) To interpret the results: Only two lines are really important for this discussion:
           Win7x64\joe)(F)  // This is because user joe created the file
           NT AUTHORITY\INTERACTIVE)(M,DC)  //  This is what gives all users on the PC
read & write access to the file

7) Now, as Administrator, run this SQL against this database:
    ALTER TABLE mytesttable ADD TestJunkColumn VARCHAR(20)

8) Run     icacls mytesttable.*   again

9) Note the results:

         C:\Users\Public\Documents\Z-Firm LLC\ShipRush\Database>icacls mytesttable.*
         mytesttable.dat NT AUTHORITY\SYSTEM)(F)
                         BUILTIN\Administrators)(F)
                         BUILTIN\Users)(RX)

         mytesttable.idx NT AUTHORITY\SYSTEM)(F)
                         BUILTIN\Administrators)(F)
                         BUILTIN\Users)(RX)
           
10) PROBLEM: At this point, joe and all other users on the PC have lost write access to
the table!


CONCLUSION: When it creates tables via CREATE TABLE, DBISAM correctly assigns inherited
permissions to .dat, .idx and other files.

However, when an ALTER TABLE command is done, the newly created .dat, .idx and other files
are NOT created with inherited permissions, causing problems for other users on the PC.

(In fact, if the PC is single user, this problem still occurs if a software installer, which
always runs as admin, performs ALTER TABLE operations -- as ours does!)

Please advise how we can correct this problem.

We are using DBISAM v4, a build from the past few months.

Thank you!

It appears the solution to this is:

 http://www.elevatesoft.com/bulletin_9.htm

We will try it out in the morning...

Yes, http://www.elevatesoft.com/bulletin_9.htm is the solution