First launch of Chrome following update removes all user temp folder permissions
Reported by
ssarg...@rvtd.org,
Mar 19 2018
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36 Steps to reproduce the problem: 1. Update Chrome using system level installer 2. User launches Chrome 3. User's AppData\Local\temp folder permissions are removed What is the expected behavior? No permission change What went wrong? Windows Security logs event 4670: Permissions on an object were changed. Subject: Security ID: DOMAIN\username Account Name: username Account Domain: DOMAIN Logon ID: 0xCD09B Object: Object Server: Security Object Type: File Object Name: C:\Users\<UserProfileFolder>\AppData\Local\Temp Handle ID: 0x1b10 Process: Process ID: 0xf8 Process Name: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Permissions Change: Original Security Descriptor: D:AI(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;S-1-5-21-2747796543-1216648981-315139365-1665)(A;OICIID;FA;;;S-1-5-21-2747796543-1216648981-315139365-1106) New Security Descriptor: D:NO_ACCESS_CONTROL Did this work before? N/A Chrome version: 65.0.3325.146 Channel: stable OS Version: 10.0 Flash Version: The user complained because another program was failing. We tracked the issue to the missing temp folder permissions. The issue recurred and we set up folder permission change tracking and found the event ID mentioned above. This is the only user in our domain (~50 users) that we have confirmed with this issue. Since this third-party program used by very few other users fails, we are in the process of inventorying user temp permissions on other machines to see if there is a discernible pattern.
,
Mar 20 2018
Thanks for filing the issue! This issue seems to be out of scope for triaging from our end as this speaks about updating Chrome using system level installer, Hence adding label TE-NeedsTriageFromHYD and requesting someone from TE-Hyd team to have a look into this issue and help in further triaging it.
,
Mar 20 2018
We have confirmed the missing user profile temp folder permissions on five more computers in our domain. We are correcting the permissions and enabling auditing to determine whether chrome.exe is captured as the process that changes the permissions. At this time we have no further correlation to report. There is no pattern of other factors that we have found that is unique to the six machines showing this symptom. The same process for updating Chrome is used on the 50 other machines in use in our domain.
,
Mar 22 2018
I took a quick stab at this by running today's canary in windbg with a breakpoint on SetSecurityInfo. I didn't find anything interesting. I'll try to take another look tomorrow using stable on a different machine. +pennymac: are you aware of any place where we may fiddle with DACLs and inadvertently change the DACL on %TEMP%?
,
Mar 23 2018
I'm unable to reproduce. Here's what I tried: - uninstall Chrome - add a custom ACL to %TMP% - "icacls %TMP%" to confirm it's there - install Chrome from https://www.google.com/chrome - wait for Chrome to launch - "icacls %TMP%" to confirm no changes Are you able to reproduce this at will? If so, could you provide a ProcMon trace showing that chrome.exe is changing the DACL of %TMP%? From that, we'll be able to see the callstack and perhaps understand what's going on. Thanks.
,
Mar 23 2018
Hey James! Any chance at all the AppContainer access control work has impacted AppData\Local\Temp? Reporter is on M65. Thanks for any triage insight!
,
Mar 24 2018
The only DACL changes which are made by the AppContainer work is in the installer, not chrome itself. Perhaps grt@ knows better than I if that still means the changes happens inside a chrome.exe process but I very much doubt it does. At any rate I certainly wouldn't expect it to affect the Temp folder and certainly not set the DACL to a NULL DACL. Also I believe any core AC work such as insaller changes were first introduced in M66.
,
Mar 26 2018
Sorry Greg, no insight!
,
Apr 2 2018
,
Apr 16 2018
OP: Are you able to record a ProcMon trace showing the ACL change on %TEMP%? We're so far unable to reproduce this or even figure out where/why Chrome might be doing it. Thanks.
,
May 31 2018
As this issue is out of scope of triaging at TE end, adding 'TE-NeedsTriageHelp' label and requesting someone from Internals>Installer team to look into the issue and help further. Thanks...
,
May 31 2018
To make any progress here, we will need a procmon trace as described in comment 10, or concrete steps to reproduce it.
,
Aug 20
Closing due to lack of feedback. Please reply if this is still an issue for you and you can provide the feedback requested in comment 10. Thanks. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by krajshree@chromium.org
, Mar 20 2018