http://bugs.winehq.org/show_bug.cgi?id=34406
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33576
--- Comment #14 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #12)
... Excellent, that confirms my original theory then - it is the inherited permissions that allow this folder to be read. So, that would make this somewhat related to Bug #33576, the fix is the same - but that bug is about specific permissions not being recalled rather than the permissions being inherited from the parent folder. I'm currently maintaining a set of patches for this as part of the Silverlight/PlayReady work I've been doing, so it'd be worth applying those patches and giving that a try: https://github.com/compholio/wine-compholio-daily/tree/master/patches/02- ACL_Extended_Attributes
Note: I just tested this and these patches, on their own, are insufficient to solve the problem for two reasons: 1) The user-specific "Application Data" does not currently have any inheritable permissions set. 2) It is additionally necessary for SetSecurityAttributes to look at the inheritable attributes (I have not implemented this yet). I'll take a look at implementing these things as soon as I can.
(In reply to comment #13)
(In reply to comment #12)
In the table it shows that when Write permission is granted (column) then special "Read Permissions" are achieved (row).
"Read Permissions" doesn't mean permission to read the file contents. It means permission to read the permissions. That is, a program with Write access can query the file's permissions, too.
That makes a lot more sense :)