os.access() under windows

[Martin v. Löwis]

Up to a point: this meets the case where we fail to access

the file at all (for read or write or whatever). But what
about where we can read the directory entry, and the
read-only attribute isn't set? At present, we'll return
True to a W_OK access check in these circs, but this user
might in fact be denied write access by the ACLs. (In fact,
they might even be denied read access, since I imagine we
only need access to the directory entry to check the
attributes).

That's my question exactly: what do you need to do
GetFileAttributes successfully?

In a POSIX world, you need read permission on the directory.
In Windows, with the "bypass-traversal-check" privilege,
you only need read permission on the directory if you want
to list it, not to access a file in the directory. Is it
actually possible for GetFileAttributes to ever fail for
security reasons?

BTW I can't see a tutorial in the AccessCheck docs here:

http://msdn2.microsoft.com/en-us/library/aa374815.aspx

or in the SDK help file. Were you referring to a different
set of docs?

I meant

http://msdn2.microsoft.com/en-us/library/aa379648.aspx

and thought it was linked from AccessCheck, but
it apparently isn't.

Regards,
Martin

 

[Tim Golden]

In a POSIX world, you need read permission on the directory.
In Windows, with the "bypass-traversal-check" privilege,
you only need read permission on the directory if you want
to list it, not to access a file in the directory. Is it
actually possible for GetFileAttributes to ever fail for
security reasons?

After a little experimentation I can confirm:

* R_OK: A process with bypass-traversal-check priv. enabled
doesn't need any access to intervening directories in order
to get the attributes of a file within them. This means that
our existing R_OK result is accurate for any file: if we can
get its attributes then you can open the file for reading.

* W_OK: If a user has *only* read permission on a file
(regardless of the intervening directories), we'll still return
True for a W_OK check, as long the file doesn't have its read-only
bit set. This means that it's possible for os.access to return True
for a W_OK check on a file which can't then be opened for, say,
appending.

* X_OK: No idea what we should do with this.

In short, no further fiddling with the existing GetFileAttributes
solution is likely to achieve anything useful. The way to go would
be to use an AccessCheck solution which mirrors the approach used
on *nix: we ask the OS to check for r/w/x and return whatever it
returns. The exact semantics of that (eg on directories) are o/s
dependent and you need to refer to the docs for more info.

I hope to make time in the next few days to put forward a patch
to implement this in posixmodule.c.

TJG

 

[Tim Golden]

[apologies if this double-posts; my email server's playing up]

> In a POSIX world, you need read permission on the directory.
> In Windows, with the "bypass-traversal-check" privilege,
> you only need read permission on the directory if you want
> to list it, not to access a file in the directory. Is it
> actually possible for GetFileAttributes to ever fail for
> security reasons?

After a little experimentation I can confirm:

* R_OK: A process with bypass-traversal-check priv. enabled
doesn't need any access to intervening directories in order
to get the attributes of a file within them. This means that
our existing R_OK result is accurate for any file: if we can
get its attributes then you can open the file for reading.

* W_OK: If a user has *only* read permission on a file
(regardless of the intervening directories), we'll still return
True for a W_OK check, as long the file doesn't have its read-only
bit set. This means that it's possible for os.access to return True
for a W_OK check on a file which can't then be opened for, say,
appending.

* X_OK: No idea what we should do with this.

In short, no further fiddling with the existing GetFileAttributes
solution is likely to achieve anything useful. The way to go would
be to use an AccessCheck solution which mirrors the approach used
on *nix: we ask the OS to check for r/w/x and return whatever it
returns. The exact semantics of that (eg on directories) are o/s
dependent and you need to refer to the docs for more info.

I hope to make time in the next few days to put forward a patch
to implement this in posixmodule.c.

TJG

 

[Martin v. Löwis]

* R_OK: A process with bypass-traversal-check priv. enabled

doesn't need any access to intervening directories in order
to get the attributes of a file within them. This means that
our existing R_OK result is accurate for any file: if we can
get its attributes then you can open the file for reading.

That cannot be. There is still an ACL on the file itself which
is considered when the file is opened for reading, namely,
the "List Folder / Read Data" permission. It may be that you need
the "Read Attributes" permission to have GetFileAttributes
succeed, but that is independent from "read data".

* W_OK: If a user has *only* read permission on a file
(regardless of the intervening directories), we'll still return
True for a W_OK check, as long the file doesn't have its read-only
bit set. This means that it's possible for os.access to return True
for a W_OK check on a file which can't then be opened for, say,
appending.

Or any other kind of writing.

* X_OK: No idea what we should do with this.

Well, there is the "Traverse Folder / Execute File" permission that
should be checked against (but currently isn't).

Regards,
Martin