I want to be able to lock a file in Win32 so that it can only be used by my current process. The most obvious way to accomplish that seemed to be via CreateFile:
HANDLE file = ::CreateFile("c:\\foo.txt",
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
However once that call has succeeded, the file is also apparently locked by my own process, ie. I get a "sharing violation" once the MFC framework stuff tries to open it.
Is there a convenient way to prevent access to the file by other processes but still allow it by mine? I'd rather not have to replace all the loading/saving framework code... Am I doing something wrong in the parameters I'm passing in to CreateFile?
From Creating and Opening Files:
An application also uses CreateFile to
specify whether it wants to share the
file for reading, writing, both, or
neither. This is known as the sharing
mode. An open file that is not shared
(dwShareMode set to zero) cannot be
opened again, either by the
application that opened it or by
another application, until its handle
has been closed. This is also referred
to as exclusive access.
See also How do the FILE_SHARE_* bits interact with the desired access bits?
I'm not aware of any simple way to do this. As far as more complex methods go, you could:
set up a special user name for accessing the file.
Open the file non-shared.
Edit the ACL to allow use only from the special user name
Close the file.
Impersonate that user
Open the file, allowing sharing
Close the file
Set the ACL back to allow other users access
Note that I'm not saying I'd recommend that at all -- it's ugly and more or less an abuse of the system -- but if you're sure you need to do this, it's one way that probably would work.
Related
I find it very very unclear what fanotify flags stand for.
Im using it for access control and would like to identify files opened for read and for write.
Taken from man:
FAN_OPEN_PERM An application wants to open a file or directory. The reader must write a response that determines whether the permission to open the filesystem object shall be granted.
Is it possible to allow only to read files, without write?
EDIT: I'm well aware of the fact that these can be realized when receiving FAN_CLOSE_WRITE and FAN_CLOSE_NOWRITE, but I want to make my access decision based on whether a file was opened for reading or for editing
In other words, is it possible to access a file without a handle being utilized?
You could use the CreateFile()-API to create a handle to the raw file-system and then parse the file structure by yourself (this is more work as it sounds!)
Though this would require admin-rights. This wouldn't trigger any hooks you have on CreateFile() or other file-related API-functions.
This wouldn't create a handle to the file but you still need a handle to the device.
For code running in user mode, any operation on a file will involve a handle of some kind, though not necessarily to the file in question. There are APIs that don't expose the handle to the programmer, but there is always one there.
In kernel mode, although it is usual to use handles for file operations, it is not necessary. For example, the file server component doesn't appear to open file handles when it is accessing a file on behalf of a remote user.
In Windows, I have an application that needs to set the access control to the user/group 'Everybody' only. And sets permissions to Read-Only. Under Linux a Simple open() call with octal 004 permissions is sufficient. On Windows, how do I accomplish the same thing? Preferably in the call to CreateFile().
Create a SECURITY_DESCRIPTOR with the proper attributes. The functions linked to from there are a good starting point for creating the proper security descriptor (it's far from trivial). This page shows a good example of creating one, including how to get the SID for the "Everybody" group (pEveryoneSID in the code).
Then, just pass in that security descriptor to CreateFile as the lpSecurityAttributes parameter.
The FileShare enumeration offers various flags such as Read, Write, Delete, ... . Normally I'd think that sharing a file for deletion only allows deletion but nothing else (like reading).
However, I remotely recall that Windows only differentiates between read-only and full access to files, so actually sharing for deletion allows writing to the file as well. Sadly this is from many years back and I neither found the original source nor any related info. Is there a reliable spec on the actual behavior? Is it dependent on the OS or the FS?
Take a look at the documentation for the CreateFile Function.
FILE_SHARE_DELETE:
Enables subsequent open operations on a file or
device to request delete access. Otherwise, other processes cannot
open the file or device if they request delete access. If this flag is
not specified, but the file or device has been opened for delete
access, the function fails. Note Delete access allows both delete and
rename operations.
The documentation doesn't mention that read access is allowed, too.
I have a problem, i have a file who opened other process and this process defined in CreateFile non file sharing, then i have other application and i want read data from this
file in same time, but how to do.
I can't change file sharing in first application.
I can reach computer administrator right's, i can do changes in system, but probably "code" solution will be better for this problem if this can be done by code.
Can anyone help me?
How about using EasyHook and hook in the API to the CreateFile routine, in effect, your code will intercept the API and possibly change the dwShareMode parameter to make it FILE_SHARE_READ bitwise or FILE_SHARE_WRITE i.e. (FILE_SHARE_READ|FILE_SHARE_WRITE) and call the original hook to allow the CreateFile to work normally...
Use the backup API if you have sufficient privilege. Otherwise, note that these flags exist for a reason. If someone disabled sharing, it's disabled.
You want to call BackupRead, and MSDN notes the following:
a backup
application must have access to the
system-level access control settings,
the ACCESS_SYSTEM_SECURITY flag must
be specified in the dwDesiredAccess
parameter value passed to CreateFile.value passed to CreateFile.
parameter value passed to CreateFile.
One of the options is to use our RawDisk product, which lets you bypass system security restrictions and open files, which have been opened exclusively or the ones for which you don't have access rights. Note, that installing RawDisk itself requires admin rights, so RawDisk can't be used for intrusion to other's computer.
Another option is to use backup API, i.e. above mentioned BackupRead() Windows API function. Doing google search for BackupAPI will give you not just description of this function, but also several comments from users about what's involved in using this backup API