How to secure a log file so that Users can only append data?

And AS AN EXTRA SPECIAL BONUS I have accidently posted this same question under the VB Controls sub-topic at:

http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/VB_Controls/Q_20691887.html

So, if you can get my log file secured for me then you could also get an extra 500 points by posting something on the above link as well.  So, that would be 1000 points.  Unless, of course, such a thing is against the rules of expert exchange managment.  I don't want to break any rules or anything.  I just posted it there by mistake.  It is just so important to me to get this thing working and it should be truly simple to do it, but I just can't make it work.  It is so frustrating to have a question that seems so simple that just turns out to be so tough.  I sware, part of me is hoping that its a bug in windows or something (not really, and I doubt it anyways).  Please help.  Thanks.....

Also, maybe check out what other people have recommended at the other link so we don't repeat stuff.  But please answer in this thread since I will be actively monitoring this thread.  Thanks (I'll be quite now).

I don't think you can use the FileSystemObject for that cause.
Because opening a file using the FSO attempts to open it for reading AND writing. And since you did not allow reading, it gives you an error.

Is there any reason why you don't want "Open for Append"? Because this one just seems to work quite fine. I really don't see a reason for using FSO.

I did both in that test program just to test different ways of appending to the end of a file.  Still, if you look you will see that I also do a normal "Open For Append".  I've also tried a few other methods that I didn't show in that test program.  In any case, it still doesn't work for me.  By the way, though I have tried setting the permissions in every way I could think of, ultimitly I would like the user to be able to read the file.  I mean, I don't mind that they see what is contained in the log file.  The only thing that I want to prevent is for the user to overwrite data (edit the data--write) or delete the file (or change the permissions, but for now I am ignoring that).

If you can think of any other ways to append in VB I could try them, but I think I have tried pretty much everything.  I am going to write a little C program to test to see that the VB append is actually an append (as far as the OS is concerned).  Though I doubt that writting the test in C will matter I just don't have any other ideas so I'll try it.

I honestly think the problem has something to do with the permission settings, but nothing I do seems to work.  Still need help!!!!!!

Well, I wrote the C program so that it opens the log file with "a" and "a+" (append directives) and the same error occurs (access denied).  It seems like I must have the write permision turned on in order to do anything to that file.  But, of course, that allows users to edit the file as well.  Then again, why the heck would Windows have an Append Permission if they don't mean for it to work?  Surely I should be able to deny the Write permission but allow the Append permission and that should do it for me.  But it doesn't work.....I am so frustrated with this silly thing.  If this was Unix I would have finished the program by now.  :(

Maybe the problem is that WinNT does not have a Append-privilege and therefore the WinNT-Server is completely confused...

And because VB 6 is somewhat older than WinXP, I don't think MS even thought of adding some routine to support Append-only.

The only workaround I can think of right now is to use a whole directory for logging instead of just a single file. But that depends on how much you have to log.
You could set only write permission to that directory. So you can create a log file (open for output) but once it's written, it can't be changed. The next time you create a log, you'll have to create a new file for it.

As I said, a very very very crude workaround. And I would not use it if I had many things to log as the directory would be getting very large (and only users with further privileges would be able to clean it up, because if you gave the user delete permission he would be able to kill a log if he knew it's filename)

Maybe VB .net has the functionality needed to make use of the append permission (and maybe not)...

Or someone else has THE great idea but has not yet looked at this Q...

Well, I'm testing this on a Win2003Server with 2 local logons-an Admin logon and a User logon.  I've created two groups called BFAdmin and BFUser that I'm using to manage the permissions (though I have also tried it on the Administrator and Users groups directly).  Most importantly this log file is meant to trace all activities within the program so it will probably get pretty large.  I can't create a file for each action, but even if I did the user would still be able to edit the files to change them.  The best I could do is to remove read and treverse access to that directory so that the user won't know what the file name is and they won't be able to load the file into an editor for editing.  But they can still overwrite the file if they figure out the name so it isn't that good a solution for me either (though as it is I might just do it that way because my client won't catch the problem--shame on me).

I wasn't aware that the Append is not available on WinNT.  I did test a WinXP client machine on a WinNT domain and the WinXP client machine had the Append permission option, so I just assumed that the WinNT server had it as well.  WinXP only allows you access to the permissions if you are attached to a Domain, so for my test environment I installed Win2003Server, but maybe I should have installed WinNT instead since that is currently more of a standard.  I'll have to check out the WinNT server to see what permissions it has (I thought it had Append).

I can't understand why Microsoft would not document such a blatent deficency in the Append permission if such a deficency exists (what am I saying...its Microsoft).  Essentially, the Append permission does nothing at all as far as I can tell.  But like you said, maybe VB and C and C++ don't support it yet.  I was also thinking that I should write some .Net code to test it, but I thought that the C/C++ code would be good enough.  I guess I'll try .Net as well (its not like the test code is that hard to write in this case).  I just didn't want to install .Net while I have 6.0 already installed (actually I just didn't want to spend time installing it).  Still, I bet you it still doesn't work (though I say that because everything I say in regards to this problem always works the oposite way-maybe reverse psychology is the trick...hee hee).

>But they can still overwrite the file if they figure out the name so it isn't that good a solution for me either
I guess that's right. But if they don't know the filename it would be some trial and error. And you could see that they tried because of many files your programm did not create. And then...

>(though I say that because everything I say in regards to this problem always works the oposite way-maybe reverse psychology is the trick...hee hee).
Then I wish you BAD luck (again, reverse psychology ;-))

>was also thinking that I should write some .Net code to test it
Since I don't hae .Net I'd be grateful if you could let me know whether it worked there or not.

OMG! FORGET ABOUT MICROSOFT!
As you know I m also  messing around with the NTFS permissions at the moment, and as I experimented around I found out something really insane. We have a Win2k server and Windows XP Prof workstations. When I for example set the only the read permission for a user on a file and he tries to delete it HE IS ABLE TO DO SO!!! EVEN WHEN I EXPLICITLY DENY DELETE THE FILE IT CAN STILL BE DELETED BY THE USER!!! I mean that cant be true, can it? I couldnt believe it but I tried again and again, checked everything and it is really true. The only way you can prevent somebody from deleting a file is not to give him any privileges.As long he is not on the list of privileged users he cant do anything, but as soon he has any privilege on the file the user can delete it. Thats absolutly wicked. Try it out on your system and tell me if you get the same result. I searched the web for it but I couldnt find anything about it. Can it be that there exists such a huge security hole and no one knows about it? Or is it just a problem with my setup? If so, it is still bad enough, because such a behavior of windows shouldnt be possible on any setup. So concerning your problem with append it is for sure possible that the append permission doesnt work at all. Maybe Microsoft thought it would be cool to be able to set an append privilege even if it has no functionality at all. Now nothing wouldnt surprise me any longer.

*confused*

I think that the delete related to the directory takes presidents over the delete for the file (or the other way around).  So, if the directory where the file is located (or more likely the directory that the file inherits from) has the delete property enabled for that particular directory then even if you disable it for a file in that directory it will still be enabled.  The strange thing is that they seem to tell you that the Deny property is supposed to take presidence, but in this case it doesn't.

Anyway, I have noticed that if you set the delete permision for the directory as well as for the file that you want to protect it will stop the delete from occuring.  I've actually started to just turn off inherritance all together for the files I'm working with.  It just makes it impossible to get the permissions working properly with it on.  For instance, why the heck does the Aministrator get denied write permission if I deny write permission for the Users group.  I believe it has something to do with the fact that it is a local logon and maybe the Administrator is temporarally set up in the Local_Users group and somehow that makes the Administrator seceptable to the Users group permisions.  But good Lord I can't figure out why that would be!!!!  I'm starting to think that Microsoft needs a new service pack or some decent documentation on permissions.  All the documentation that I can find pretty much says exactly what I suspected it to say, but it doesn't do what its suppose to do.  Its so frustrating.  That Append permission could be quite useful if they would make it work properly.

Ok you are right. It s so funny though.
If you have one directory with one file in it Microsoft implemented permissions like this:

Delete Directory          Delete File          Delete Directory Attempt          Delete File Attempt

Allowed                       Allowed              Success                                     Success
Allowed                       Denied               Success                                     Success
Denied                        Allowed              Success                                     Success
Denied                        Denied                Fail                                            Fail


So what kind of sense does that make?????????
Why would anybody need to set permissions for files and directories seperatly when they correspond like this?
I dont get it. How stupid can a MS programmer be? And what about the millions of users worldwide, the thousands of system administrators and the hundreds of windows book authors? Did no one ever complain at MS? Nothing I read about NTFS permissions so far even mentioned this stupid bug. I mean come on this is Windows the number one OS in the world you cant sell **** lwith bugs like this in such an essential field like security and permissions. Sad but true, apparently you can.

I thought that as well, but I've tried the test in VB6, VB.Net, C/C++.  I figured if C/C++ can't do it then nothing could.  Why do they even have the Append permission if they don't even have any system functions that support it.  I mean, I understand that maybe VB won't do it, but surely if Append is appart of the OS then they must provide some API methods of utilizing them.  I just can't find anything on the subject at all.  Its just so hard to see every site simply mention the Append permission as if it is no big deal to use it.  Well, it is a big deal to use it.  They should say something like...."Well, the Append permission is suppose to allow you to append data to the end of the file but it is currently not supported by anything so at this time it is actually just a check box on the permission screen that sets a permission flag that is never used by anything".  Wouldn't that be more discriptive?  hee hee.

I'm just so frustrated with this.  And not just this Append permission, but with permissions in general.  They seem to act in some way that is not predictable.  Some of them work fine, but others just don't work right.  I mean, log in as Administrator and create a simple text file.  Then set the write permission to deny for the Users group (and only the Users group).  Then while you are still logged in as Administrator try to see if you can edit the file with notepad.  You can't!!!!!!!  Why the heck?  What does the User permissions have to do with the Administrator.  Its just nonsense and soooooooooo frustrating.  I thought that maybe the Administrator was somehow associated with the Users group if he/she logs on locally.  Or maybe there is some permissions related to the application that you are running (like Notepad).  Maybe since Notepad is a program that users can use then if the administrator runs that application the files that that program opens are opened as if it was a User even if it was the administrator.  But that is just nonesense as well.  This is just bottom of the barrel thinking on my part.  It doesn't make sense to me at all.

Still, I'll try .Net again (since it is the newest compiler I have) and see if there is some other methods of openning for Append.  Arrrrrrrggggggghhhhhhhhhh!!!!!!!  hee hee.

Just had some other thought:
Why don't keep your program running keeping the file open?

When your program is started, open the file and locking it and don't close it until your program is shutdown. I mean, something like that:

Private Sub Form_Load()
   sFileNo = FreeFile
   Open "E:\test\lock.txt" For Binary Lock Write As sFileNo  'Lock write prevents other processes from writing there
End Sub

Private Sub Form_Unload(Cancel As Integer)
   Close sFileNo
End Sub

Now you have to find a way to prevent the user from closing your program. This coul be running it as a service (http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/Q_20098147.html) or just hiding it using App.TaskVisible = False.

Steiner, I can't allow the user to modify the file weather the program is running or not running.  This file is supposed to log activities within a program to meet the national standards related to the pharmaceutical industry.  Pharmaceutical scientists are not allow to make modifications to data without it being traceable (no fudging data....though in reality they really don't fudge data and it this feature is just a method to monitor human error rather then deliberate fraud).

Anyway, I can't allow a user to run the program and change some data and then exit the program and load the log file into notepad and erase the trace of what changes they have made.  Clearly, a great deal of the traceability is already associated with the data itself, so to some extent I have already prevented much of the fraud that could occur, but the log file covers all the other areas of the program where data could be changed, or users could be monitor trying to hack into the system, or whatever.  I can't allow it to be changed by the user that is instigating the attack on the application.

I also cannot dedicate the computer that the scientists are using to my application.  They need to use the computer for all sorts of other applications.  Its just not going to be a practical solution to try to force my application to be running all the time.

I think I know of a way to answer my own question that I don't want to do.  I could create a system process that has write access to the log file and then try to write my application to communicate with the system process to reqest that it writes the message to the log file for my application.  Its just that that would be a lot more work, if it were even possible.  I might still try it, but I am really not looking forward to it since it is new territory for me.  And since all I need is for the Append permission to work properly I can't believe that I need to even consider all that much more work for what should be 3 lines of code in my program to append to the log file.  It makes me sooooooooo mad......I think I would rather put more effort into trying to get my client to accept the program without the log file if I gotta work that much harder to get it to work.

TomBrowett: Yes, that was what I was thinking as well.  I couldn't find any documentation on those hidden groups so I have been working on a group that I've created instead just to avoid thinking about them.

@Enlade:
I think you did not get me right.
The user is NOT SUPPOSED to end your program. What I meant is, that your program is started when the user logs on and is not finished until he logs off again. So even when the user thinks he exit's your program, it's just hidden and keeps running therefore keeping then log-file open.

How much effort you need to prevent the user from force-shutting-down your program depends on your users.

The problem is you cant prevent a user to end the programm. Neitherit prevents anybody from closing it. running it as a service nor hidding. You are always able to list the processes on your machine and kill them.

I think Schmida is correct.  I can't think of any way to prevent the user from shutting down a process that he starts.  However, maybe there is a way to start the process through some other user (SYSTEM, Admin, or something) and make that running process availabe to the users of my application.  In such a case I don't need my full application running but simply a small application that takes a string and puts it into the lag flie (lag file....sheesh...I've been playing Subspace too long--I mean Log file).  The only problem is that I don't know how to do that and it seems like a lot more work just to do what the Append permission should have done for me in the first place.  Nevertheless, I'll see if I can figure out how to create a process that is owned by the SYSTEM (something I'd like to know more about anyways) and not the user who is logged in.  That would also work if it is possible to do such a thing in WinXP (I am thinking it is--or something similar).  At this point I am pretty sure that the Append permission is meaningless and Microsoft should really document it as such (but I'm still hoping).

There really wasn't any solution to this problem except maybe to set up a windows service or something.  Maybe with the next release of VB or the OS it will be possible to make use of that Append file property, but for now there is no easy way to do it.  In any case, I will split the points because I did get some interest in this message (and also in my other thread).  I'll split the points this week sometime when I have a chance to review all the above answers again.