http://bugs.winehq.org/show_bug.cgi?id=34406
Bug #: 34406 Summary: regression: Finale Notepad 2012 doesn't copy/create user files on program start Product: Wine Version: 1.7.0 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs@winehq.org ReportedBy: s_chriscollins@hotmail.com Classification: Unclassified
Program: Finale NotePad 2012 (free download) Download URL: http://www.finalemusic.com/products/finale-notepad/ Commit causing regression: 5851032d07c321f2c050187115cfd8e21b5f3f49 (advapi: Implement SetNamedSecurityInfoW on top of SetSecurityInfo.)
Reproducing the Bug: 1) Download and install Finale NotePad 2012. 2) Run the Finale Notepad 2012 application. 3) Click "OK" or "Continue" on all the dialogs, and then you'll get to a registration dialog. Click "Remind Me Later".
Result: Finale throws an error: "Finale NotePad cannot start the Wizard because a necessary data file (Maestro Font Default.FTM) could not be found."
Expected result: NotePad should bring up the new song wizard, which it does correctly using Wine 1.4 and all versions leading up to the commit listed above.
Here's what appears to be happening: When installing Finale NotePad, default user files are copied to "drive_c/users/Public/Application Data/MakeMusic". When running the NotePad application for the first time after installation, files are copied from this public location to the current user at "drive_c/users/[username]/Application Data/MakeMusic", and some additional configuration files are created in this same location.
After the regression, these user-specific files are never copied/created, causing NotePad to throw the error. Once these files are created, perhaps by an earlier version of Wine, NotePad will run even in newer versions of Wine.
http://bugs.winehq.org/show_bug.cgi?id=34406
S. Christian Collins s_chriscollins@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5851032d07c321f2c050187115c | |fd8e21b5f3f49
http://bugs.winehq.org/show_bug.cgi?id=34406
S. Christian Collins s_chriscollins@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #1 from S. Christian Collins s_chriscollins@hotmail.com 2013-08-31 13:02:15 CDT --- I should also mention, I tested this with the latest git as of yesterday (8/30/2013) and the bug is still present.
http://bugs.winehq.org/show_bug.cgi?id=34406
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.finalemusic.com/ | |products/finale-notepad/
http://bugs.winehq.org/show_bug.cgi?id=34406
S. Christian Collins s_chriscollins@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=34406
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
--- Comment #2 from Erich Hoover erich.e.hoover@gmail.com 2013-09-20 19:22:22 CDT --- I just noticed this on my regression list and took a moment to take a quick look at it before heading out the door. It appears that the application is changing the access to the folder to be write-only with its SetNamedSecurityInfo call, so that's why the copy doesn't occur. It's possible that NtSetSecurityObject isn't properly parsing the DACL, as there doesn't appear to be anything wrong with the SetNamedSecurityInfo or SetSecurityInfo implementation (with regard to what this application wants).
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #3 from Erich Hoover erich.e.hoover@gmail.com 2013-11-06 15:56:03 CST --- (In reply to comment #1)
I should also mention, I tested this with the latest git as of yesterday (8/30/2013) and the bug is still present.
I'm finally getting around to digging into this a little bit, would you mind seeing what happens permissions-wise on Windows for the user's "Application Data/MakeMusic" folder? I suspect that it's setting world-writable permissions (exclusively) and inheriting permissions from the parent folder that allows the user to continue to read the files.
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #4 from S. Christian Collins s_chriscollins@hotmail.com 2013-11-11 12:53:40 CST --- (In reply to comment #3)
I'm finally getting around to digging into this a little bit, would you mind seeing what happens permissions-wise on Windows for the user's "Application Data/MakeMusic" folder? I suspect that it's setting world-writable permissions (exclusively) and inheriting permissions from the parent folder that allows the user to continue to read the files.
That is what it appears to be doing on Windows. The user's MakeMusic folder and subfolders have the following permissions: User: Everyone Basic Permissions: Write, Special permissions Advanced Permissions: Create files/ write data Create folders/ append data Write attributes Write extended attributes Read permissions
User: SYSTEM / Administrators / Owner Basic Permissions: Full control
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #5 from Erich Hoover erich.e.hoover@gmail.com 2013-11-11 12:56:30 CST --- (In reply to comment #4)
... That is what it appears to be doing on Windows. The user's MakeMusic folder and subfolders have the following permissions: User: Everyone Basic Permissions: Write, Special permissions Advanced Permissions: Create files/ write data Create folders/ append data Write attributes Write extended attributes Read permissions
User: SYSTEM / Administrators / Owner Basic Permissions: Full control
What does it say under the "Inherited From" column?
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #6 from S. Christian Collins s_chriscollins@hotmail.com 2013-11-11 13:04:57 CST --- (In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris".
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #7 from Erich Hoover erich.e.hoover@gmail.com 2013-11-11 17:38:22 CST --- (In reply to comment #6)
(In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris".
Hmmm, the only permissions I see it setting are 0x40000000 (GENERIC_WRITE)...
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #8 from Erich Hoover erich.e.hoover@gmail.com 2013-11-25 18:45:07 CST --- (In reply to comment #7)
(In reply to comment #6)
(In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris".
Hmmm, the only permissions I see it setting are 0x40000000 (GENERIC_WRITE)...
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
it appears that write permission on a folder implies read permissions. I'm not entirely sure how we need to handle that internally, but that probably explains what's going wrong here. I can hopefully write a test case for this pretty easily, so that should help narrow down the solution space.
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #9 from Erich Hoover erich.e.hoover@gmail.com --- I'm having trouble with GENERIC_WRITE implying read (I can't find a test that reproduces this possible behavior). So, I created a small program to list out all the permissions for your folder: https://dl.dropboxusercontent.com/u/195059/wine/test.exe https://dl.dropboxusercontent.com/u/195059/wine/test.c (source)
So, if you could run (on Windows with the actual folder): test.exe "C:\users\Public\Application Data\MakeMusic" and then send me the output I'd appreciate it.
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #10 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to comment #8)
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
it appears that write permission on a folder implies read permissions.
I can't find that assumption in that article:
Permissions for Files and Folders:
List Folder/ Read Data: List Folder allows or denies viewing file names and subfolder names in the folder. List Folder only affects the contents of that folder; it does not affect whether the folder you are setting the permission on will be listed. (Applies to folders only.) Read Data allows or denies viewing data in files. (Applies to files only.)
Create Files/ Write Data: Create Files allows or denies creating files in the folder. (Applies to folders only.) Write Data allows or denies making changes to the file and overwriting existing content. (Applies to files only.)
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #11 from S. Christian Collins s_chriscollins@hotmail.com --- I ran test.exe in both Windows 8 and Windows XP. The program crashed in XP, so I only have the Windows 8 results.
Windows 8 ("C:\ProgramData\MakeMusic"):
sid: S-1-1-0, mask: 0x120116, flags: 0 sid: S-1-5-18, mask: 0x1f01ff, flags: 13 sid: S-1-5-32-544, mask: 0x1f01ff, flags: 13 sid: S-1-3-0, mask: 0x10000000, flags: 1b sid: S-1-5-32-545, mask: 0x1200a9, flags: 13 sid: S-1-5-32-545, mask: 0x116, flags: 12
http://bugs.winehq.org/show_bug.cgi?id=34406
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #12 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #10)
(In reply to comment #8)
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
it appears that write permission on a folder implies read permissions.
I can't find that assumption in that article: ...
In the table it shows that when Write permission is granted (column) then special "Read Permissions" are achieved (row). I'm not sure this is actually the case after doing some testing.
(In reply to comment #11)
... sid: S-1-1-0, mask: 0x120116, flags: 0 sid: S-1-5-18, mask: 0x1f01ff, flags: 13 sid: S-1-5-32-544, mask: 0x1f01ff, flags: 13 sid: S-1-3-0, mask: 0x10000000, flags: 1b sid: S-1-5-32-545, mask: 0x1200a9, flags: 13 sid: S-1-5-32-545, mask: 0x116, flags: 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...
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #13 from Ken Thomases ken@codeweavers.com --- (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.
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 :)
http://bugs.winehq.org/show_bug.cgi?id=34406
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|regression: Finale Notepad |Finale Notepad 2012 doesn't |2012 doesn't copy/create |copy/create user files on |user files on program start |program start
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #15 from Erich Hoover erich.e.hoover@gmail.com --- It's taken me quite a while to rewrite my patches to handle this case, but I've posted an updated version that should fix your issue: https://github.com/compholio/wine-compholio-daily/tree/master/patches/02-ACL...
These patches implement the following changes: 1) File ACLs are stored in Extended Filesystem Attributes on the system 2) When creating a directory with security attributes attached then attributes are inherited from parent folders 3) When setting the attributes on a file (or directory) without the PROTECTED_DACL_SECURITY_INFORMATION flag then attributes are inherited from parent folders 4) The creation of user shell folders now has inheritable ACLs for the user and administrator
Patch installation instructions: 1) Apply the patches (patch -p1 < patch-to-apply.path) 2) Update the configure script (autoreconf) 3) Run the updated configure script (./configure) 4) Compile and install the updated Wine (make && sudo make install)
Note that your file system and kernel must support Extended Filesystem Attributes and the development library headers must be installed. If you give me more details about your system (distro, version, etc.) I can help you if getting things working poses a problem.
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #16 from S. Christian Collins s_chriscollins@hotmail.com --- I'm ready to test this out. I'm using Kubuntu 12.04 with kernel 3.5.0-45-generic. Do I need to add the "user_xattr" flag to the fstab entry for my home folder for this to work?
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #17 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #16)
I'm ready to test this out. I'm using Kubuntu 12.04 with kernel 3.5.0-45-generic. Do I need to add the "user_xattr" flag to the fstab entry for my home folder for this to work?
If you are using ext3 then yes, if you are using ext4 then extended attributes are enabled by default. You can use the following to test whether extended attributes are enabled: touch ~/.xattr_test && setfattr -n 'user.testAttr' -v 'attribute value' ~/.xattr_test &> /dev/null; getfattr ~/.xattr_test 2>&1 | grep -q user.testAttr && echo 'It works!' || echo 'No extended attribute support!'; rm ~/.xattr_test &> /dev/null
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #18 from S. Christian Collins s_chriscollins@hotmail.com --- I can confirm that the patches do indeed resolve this bug. Cheers, mate! :)
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #19 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #18)
I can confirm that the patches do indeed resolve this bug. Cheers, mate! :)
Great! I need to wait to submit these until I have some other patches accepted, but these patches are pretty high on my priority list after that.
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #20 from S. Christian Collins s_chriscollins@hotmail.com --- What is the current status of these patches?
http://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #21 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to S. Christian Collins from comment #20)
What is the current status of these patches?
They went through a pretty major revision recently ( still available at https://github.com/compholio/wine-compholio-daily/tree/master/patches/02-ACL... ) and, after a little more testing and small cleanup, should be ready for submission. However, these are complicated changes to the wineserver and I need to finish getting my other wineserver changes upstream first (support for SIO_ADDRESS_LIST_CHANGE). I've been working on getting these changes in for about a year now and I've only just recently got the first patch accepted, so I'm not about to switch gears and move over to the ACL patches until the SIO_ADDRESS_LIST_CHANGE patches are upstream.
http://bugs.winehq.org/show_bug.cgi?id=34406
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30489
http://bugs.winehq.org/show_bug.cgi?id=34406
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|30489 |
https://bugs.winehq.org/show_bug.cgi?id=34406
Terran reid@halfcadence.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |reid@halfcadence.net
--- Comment #22 from Terran reid@halfcadence.net --- I can confirm that I'm able to start Finale 2012 and open/create files properly using a build with these patches applied.
https://bugs.winehq.org/show_bug.cgi?id=34406
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #23 from Sebastian Lackner sebastian@fds-team.de --- Just to make sure, that everyone looking into this bug actually finds the latest version of our patches - they are available at:
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-DOS... https://github.com/wine-compholio/wine-staging/tree/master/patches/server-St... https://github.com/wine-compholio/wine-staging/tree/master/patches/server-In...
Please note that the patches depend on each other, dependency information and other metadata can be found in the "definition" file in each directory. Our repository contains also further ACL related patches, but the three mentioned above should be sufficient to fix the issue described here.
https://bugs.winehq.org/show_bug.cgi?id=34406
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #24 from Piotr Caban piotr.caban@gmail.com --- It works for me now. Please retest.
https://bugs.winehq.org/show_bug.cgi?id=34406
--- Comment #25 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Piotr Caban from comment #24)
It works for me now. Please retest.
S. Christian Collins: Have you had a chance to retest with unpatched Wine? It would be nice to confirm that this issue is resolved.
https://bugs.winehq.org/show_bug.cgi?id=34406
S. Christian Collins s_chriscollins@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #26 from S. Christian Collins s_chriscollins@hotmail.com --- I can confirm that this bug has indeed been fixed! Tested using Wine 1.7.45.
https://bugs.winehq.org/show_bug.cgi?id=34406
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.46.