How to check if a file can be created inside given directory on MS XP/Vista?

Question

I have a code that creates file(s) in user-specified directory. User can point to a directory in which he can't create files, but he can rename it.

I have created directory for test purposes, let's call it C:\foo.

I have following permissions to C:\foo:

• Traversing directory/Execute file
• Removing subfolders and files
• Removing
• Read permissions
• Change permissions
• Take ownership

I don't have any of the following permissions to C:\foo:

• Full Control
• File creation
• Folder creation

I have tried following approaches, so far:


os.access('C:\foo', os.W_OK) == True

st = os.stat('C:\foo')
mode = st[stat.ST_MODE]
mode & stat.S_IWRITE == True

I believe that this is caused by the fact that I can rename folder, so it is changeable for me. But it's content - not.

Does anyone know how can I write code that will check for a given directory if current user has permissions to create file in that directory?

In brief - I want to check if current user has File creation and Folder creation permissions for given folder name.

EDIT: The need for such code arisen from the Test case no 3 from 'Certified for Windows Vista' program, which states:

1. The application must not allow the Least-Privileged user to save any files to Windows System directory in order to pass this test case.

Should this be understood as 'Application may try to save file in Windows System directory, but shouldn't crash on failure?' or rather 'Application has to perform security checks before trying to save file?'

Should I stop bothering just because Windows Vista itself won't allow the Least-Privileged user to save any files in %WINDIR%?

Answer 1

I recently wrote a App to pass a set of test to obtain the ISV status from Microsoft and I also add that condition. The way I understood it was that if the user is Least Priveledge then he won't have permission to write in the system folders. So I approached the problem the the way Ishmaeel described. I try to create the file and catch the exception then inform the user that he doesn't have permission to write files to that directory.

In my understanding an Least-Priviledged user will not have the necessary permissions to write to those folders, if he has then he is not a Least-Priveledge user.

Should I stop bothering just because Windows Vista itself won't allow the Least-Privileged user to save any files in %WINDIR%?

In my opinion? Yes.

Answer 2

I wouldn't waste time and LOCs on checking for permissions. Ultimate test of file creation in Windows is the creation itself. Other factors may come into play (such as existing files (or worse, folders) with the same name, disk space, background processes. These conditions can even change between the time you make the initial check and the time you actually try to create your file.

So, if I had a scenario like that, I would just design my method to not lose any data in case of failure, to go ahead and try to create my file, and offer the user an option to change the selected directory and try again if creation fails.

Answer 3

I agree with the other answers that the way to do this is to try to create the file and catch the exception.

However, on Vista beware of UAC! See for example "Why does my application allow me to save files to the Windows and System32 folders in Vista?": To support old applications, Vista will "pretend" to create the file while in reality it creates it in the so-called Virtual Store under the current user's profile.

To avoid this you have to specifically tell Vista that you don't want administrative privileges, by including the appropriate commands in the .exe's manifest, see the question linked above.

Answer 4

import os
import tempfile

def can_create_file(folder_path):
    try:
        tempfile.TemporaryFile(dir=folder_path)
        return True
    except OSError:
        return False

def can_create_folder(folder_path):
    try:
        name = tempfile.mkdtemp(dir=folder_path)
        os.rmdir(name)
        return True
    except OSError:
        return False