File Security

Topic

New Reply

I have been going in circles looking for a way to set a file to allow it to be written to but not read, printed, or copied. The security does not need to be perfect, since I am just looking for a way to have better protection than none at all.

The file is written to by an application (I have multiple versions of this application on each of several machines; a different version is created annually). The developers are morons, so even though they store the customer ID and Password securely (and replace the password with asterisks when it is typed), they write it to a plain text log every time the application communicates with the server (which is several times a day). Hence, I want to protect this file from being viewed/copied/printed while the disk is decrypted (which it must be while the application is running).

I realized today that I can change the file permissions for each user such that they can write to the file but not TYPE it, nor open it in NOTEPAD nor Word, nor PRINT it nor COPY it. However, I can still leave this file there so that it is available to the application for writing.

Currently, I have the following permissions set up for a test file and think this may be what I need:

Basic:
[INDENT]Full Control: NO
Modify: NO
Read & execute: NO
Read: NO
Write: YES
Special permissions: YES[/INDENT]

Advanced:
[INDENT]Full Control: NO
Traverse folder / execute file: NO
List folder / read data: NO
Read attributes: YES
Read extended attributes: YES
Create files / write data: YES
Create folders / append data: YES

Write attributes: YES
Write extended attributes: YES
Delete: NO
Read permissions: YES
Change permissions: NO
Take ownership: NO[/INDENT]

I was able to pipe data to this file using a batch file with an ECHO command but was not able to open it in any of the applications I tried to use (which is the behavior I believe I need). It appears on directory lists and in File Explorer (but not in the preview window).

I realize this may not be perfect, but it seems to achieve the goals I was trying to achieve. Can anyone think of a problem I might cause with the above permissions? Perhaps I should allow deleting the file, but I am unsure if the file would then be unprotected in the Recycle Bin.

Any thoughts at all would be appreciated.

Thanks.

Reply | Quote

Replies

If the app attempts to list the directory contents to see if the log file already exists then it will fail unless you allow List Folder.

I can’t see why you need extended attributes, the basic permissions should be sufficient with no special permission.

If the file is deleted all permissions are lost, so you would have to re-apply them to a new file. You could try granting write only permission to the directory.

The recycle bin is only used when files are deleted from the GUI / DOS etc, not programatically.

cheers, Paul

Reply | Quote

Thanks, Paul,

The way I was interpreting that “permission” is that the “list folder” option is what that setting would apply to at the folder level, but “read data” would apply at the file level. What I did not state clearly is that I intend to apply this change solely at the file level.

In my tests, I can see the entire directory in File Manager or when using the DIR command.

Reply | Quote

As the permission is at file level you would expect to be able to see all files.
Remember that deleting the file deletes the permissions.

cheers, Paul

Reply | Quote

Thank you again, Paul.

One of the reasons I am testing this is that I do not think this file is actually ever deleted, but is just written to; hence the “no delete” option. If the file is deleted, I actually have another problem since the file becomes available in the Recycle Bin. Hopefully the application never needs to delete these files.

Reply | Quote

The file permissions will travel with the file to the recycle bin.

cheers, Paul

Reply | Quote