[ python-Bugs-991735 ] os.access reports true for read-only directories

[SourceForge.net]

Bugs item #991735, was opened at 2004-07-15 12:08
Message generated for change (Comment added) made by mkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2004-07-29 14:28

Message:
Logged In: YES 
user_id=555

The submitter seems to want os.access to agree with the
subsequent behavior of I/O operation, but this is not
possible for all cases.  The NFS spec, for example, allows
NFS servers to deny operations in a capricious manner, over
and above any denial that might be due to permissions bits
and/or a volume "read only" flag.  I don't know if there is
an SMB/CIFS server spec, but one could imagine the same
thing happening there.

It might be possible to add ACL checking to the Windows
version of os.access, if a Windows person thinks it's
worthwhile.  It probably would be valuable to add a
clarification to the os.access doc.  For example:

Note that I/O operations may fail even when the access
function indicates that they would succeed, particularly for
operations on network filesystems, which may have
permissions semantics beyond the usual POSIX permission-bit
model.

(Also, if someone does this, please update the doc to note
that access returns True and False, not 1 and 0.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 15:59

Message:
Logged In: YES 
user_id=31435

Heh -- I didn't know it either, Thomas.  But I've also noticed 
how many new Windows bugs get assigned to you, and got 
curious enough to dig into it.

----------------------------------------------------------------------

Comment By: Mark Moales (mmoales)
Date: 2004-07-15 14:25

Message:
Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 14:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 13:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 13:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470