tracker issue : CF-4175138

select a category, or use search below
(searches all categories and all time range)
Title:

[ANeff] Bug for: imageWrite applies temp directory permissions in some cases

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 07/22/2016

Components: CFIMAGE

Versions: 2016,11.0,2018

Failure Type:

Found In Build/Fixed In Build: CF2016_Update2 / 313274

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Win All

Vote Count: 2

imageWrite applies temp directory permissions in some cases

Steps to Reproduce:
--------------------------------------------
1) unzip attached ImageWriteAppliesTempDirectoryPermissions.zip
2) run index.cfm
3) see* foo2.jpg's Windows file permissions are same as parent folder's permissions (good)
4) run index.cfm?filename=bar
5) see* bar2.jpg's Windows file permissions are same as CF's temp directory's permissions (bad)

* - to see Windows file permissions, right-click the file and choose Properties and click "Security" tab

Actual result: see #3 and #5

Expected result (and actual result in CF11): images created by imageWrite() always inherit permissions from parent directory (not from CF's temp directory)

Reproduced the issue on Windows 2008 and Windows 2012 R2 w/ CF2016 Enterprise Final, CF2016 Enterprise Update 1 and CF2016 Enterprise Update 2 with and without Lockdown Guide steps applied.

Unable to reproduce the issue on Windows 10. Tried on two Windows 10 machines w/ CF2016 Developer Edition Update 1 and Update 2 and always got expected results.

index.cfm
--------------------------------------------
<cfscript>
  fileName = (URL.keyExists("fileName") and listFindNoCase("foo,bar", URL.fileName)) ? URL.fileName : "foo";
  myImage = imageRead(expandPath("./#variables.filename#.jpg"));
  imageWrite(myImage, expandPath("./#variables.filename#2.jpg"), 1, true);
</cfscript>

Possibly related to 3114274.

Note: foo.jpg was edited in Photoshop. bar.jpg is from Google image search. Issue possibly caused by corrupted metadata?

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4175138

Reason:	PRNeedInfo

External Customer Info:
External Company:  
External Customer Name: Aaron Neff
External Customer Email:

Attachments:

  1. July 23, 2016 00:00:00: 1_ImageWriteAppliesTempDirectoryPermissions.zip
  2. August 18, 2016 00:00:00: 2_Metadata_Bar.png
  3. August 18, 2016 00:00:00: 3_Metadata_Foo.png

Comments:

Hi Aaron, Tried to repro the issue with Enterprise on the specified machines, could not repro it. Could you please mention the user permissions of the CF server. Thanks, Preethi
Comment by S P.
2121 | July 27, 2016 08:35:07 AM GMT
Hey Aaron, Do let us know if there is any information that could help us repro this issue, so that we could try to incorporate a fix for the same in the upcoming updates itself. Thanks, Preethi
Comment by S P.
2122 | August 08, 2016 02:30:37 AM GMT
Hi Preethi, CF2016 has full control permissions for the parent folder. I observed the issue on two Windows 2012R2 servers and a Windows 2008 server, but not on any Windows 10 machines. I observed the issue w/ bar2.jpg, but not foo2.jpg. It seems CF has trouble w/ bar2.jpg's metadata. This issue is very problematic as there is no workaround. Thanks very much for looking into this!, -Aaron
Comment by External U.
2123 | August 12, 2016 04:38:38 PM GMT
Also, issue is observed regardless of whether CF is locked-down or not. I verified issue on a default install of CF2016 Ent standalone.
Comment by External U.
2124 | August 12, 2016 04:42:30 PM GMT
Oops, typo: The "It seems CF has trouble w/ bar2.jpg's metadata." should've been "It seems CF has trouble w/ bar.jpg's metadata.".
Comment by External U.
2125 | August 12, 2016 04:46:23 PM GMT
Hi Aaron, PFA Attached the metadata details for the images foo.jpg & bar.jpg, was able to successfully retrieve the details. And was able to do it on both Windows 2012 R2 as well 2008. Also, another observation, in the cases that I verified, both the images seemed to have same permissions different from the parent folder. Could you share the metadata details for the images and also as to how different are the permissions for the images. Also please do share any environment details that I might be missing to be able to repro this scenario. Thanks, Preethi
Comment by S P.
2126 | August 17, 2016 11:00:57 PM GMT
Hi Preethi, I will follow-up today on this w/ more details. Thank you for your help!, -Aaron
Comment by External U.
2127 | August 31, 2016 02:37:44 AM GMT
Hey Aaron, Any updates wrt the details. Thanks!
Comment by S P.
2128 | September 05, 2016 11:26:28 PM GMT
Hi Preethi!, Very sorry for the delay. I -think- the issue only arises if Lockdown Guide is applied. In the description, I said it did not matter if Lockdown Guide was applied or not. But, I think I was wrong there. I'll test today and follow-up. Thanks!, -Aaorn
Comment by External U.
2129 | September 07, 2016 01:41:31 AM GMT
Hey Aaron Any insights? Thanks!
Comment by S P.
2130 | September 22, 2016 04:18:17 AM GMT
Hi Preethi, On a locked-down server, if source .jpg's metadata contains the ExifByteOrder tag, and the CF user has delete permissions on imageWrite()'s destination directory, then imageWrite()'s destination .jpg inherits file permissions from {CFRoot}\cfusion\tmpCache\CFFileServlet\_cf_image (instead of from destination directory). Repro case (get exiftool.exe from http://www.sno.phy.queensu.ca/~phil/exiftool/): 1) On Windows, apply Lockdown Guide and have CF and IIS run as dedicated users. 2) Create a folder and give IIS Application Pool and Anonymous Authentication accounts read permissions on it. 3) Give the CF user read+write+delete permissions on the folder that was just created (important: CF must also have delete permissions, not just read+write) 3) Run the following code from the folder that was just created: ----------- <cfscript> imageWrite(imageRead("http://blogs.coldfusion.com/assets/content/Tridib/cf-evolution-newest.JPG"), expandPath("./cf-evolution-newest-bad.JPG"), 1, true); imageWrite(imageRead("http://blogs.coldfusion.com/assets/content/Tridib/cf-evolution-newest.JPG"), expandPath("./cf-evolution-newest-good.JPG"), 1, true); cfexecute(name="#expandPath('./exiftool.exe')#", arguments="-ExifByteOrder= -exif:Copyright=MyCopyright #expandPath("./cf-evolution-newest-good.JPG")#", timeout=10);//note: currently, the only way to remove the ExifByteOrder tag is to simultaneously write additional metadata (that is why I included -exif:Copyright=MyCopyright, otherwise ExifByteOrder tag is not removed from the file) </cfscript> ----------- Actual result: "Security" tab of Windows file properties for cf-evolution-newest-good.JPG shows permissions are inherited from parent directory (IIS permissions are included). Good. "Security" tab of Windows file properties for cf-evolution-newest-bad.JPG shows permissions are inherited from {CFRoot}\cfusion\tmpCache\CFFileServlet\_cf_image (IIS permissions are excluded). Bad. Expected result: imageWrite()'s destination file should always inherit permissions from its destination directory. This bug creates a problem when imageWrite() copies images (or saves images that were uploaded via form submit) (including images created via Photoshop) and IIS doesn't have permission to serve them. Thanks!, -Aaron P.S. tracker.adobe.com notifcations do not get sent to customers. If you need to reach me for more details, please email me. Thanks!
Comment by Aaron N.
2131 | January 31, 2017 10:09:39 AM GMT
To view the ExifByteOrder: 1) download exiftool.exe from http://www.sno.phy.queensu.ca/~phil/exiftool/ 2) download ExifToolGUI.exe from http://u88.n24.queensu.ca/~bogdan/ 3) Place both .exe in same folder 4) Run ExifToolGUI.exe 5) On the left, and in the center, browse to and select a .jpg file 6) On the right of the UI, under "Metadata", click "ALL" 7) Scroll down to the "---- File ----" section. 8) If "ExifByteOrder" exists, then imageWrite() will not handle that image properly. If no "ExifByteOrder" exists, then imageWrite() will handle the image properly. Thanks!, -Aaron
Comment by Aaron N.
2132 | February 02, 2017 06:08:46 AM GMT
To clarify.. 8) If "ExifByteOrder" exists, then imageWrite() will not handle that image properly. If no "ExifByteOrder" exists, then imageWrite() will handle the image properly on a locked-down server if the CF service user has R/W/D permissions on the destination directory.
Comment by Aaron N.
2133 | February 02, 2017 06:10:48 AM GMT
Wow, what an odd bug! I can confirm that I am seeing the same behavior on my system. Would be nice to get this fixed!
Comment by Masha E.
2134 | February 15, 2018 02:50:53 PM GMT
I guess I should point out the system properties: Windows 2016, ColdFusion 2016 with update 5 installed. Thank you Aaron for figuring out! I am applying the same permissions to the temp folder as a workaround, rough!
Comment by Masha E.
2135 | February 15, 2018 02:53:01 PM GMT
Please fix!
Vote by Masha E.
2136 | February 15, 2018 02:54:42 PM GMT
Hi Adobe and Masha, I'm surprised this issue isn't fixed yet. Adobe: CF-4201982 is possibly a duplicate of this one? Thanks!, -Aaron
Comment by Aaron N.
27574 | April 17, 2018 05:05:04 AM GMT