This reverts commit 36ea585db1.
http://crrev.com/c/3691982 introduced DisposeStoragePartition
to ditch the one-time storage partition used in ChromeOS sign-in.
It turns out it is unsafe to dispose SPs because they could
referenced later, even after <webview> referencing them are
destroyed. We hit UAF like in http://crbug/1382971. This CL
removes the unsafe API.
The memory issue will be fixed in a different way.
Bug: 1308831, b:260522812
Change-Id: Ic6d1b219037f8424bc8031415b7cd2e2238336fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4184936
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1095918}
Each gaia sign-in attempt creates an in-memory storage partition.
After the sign-in attempt, the storage partition needs to be disposed.
Otherwise, they are kept around indefinite, which wastes memory.
Bug: 1308831
Cq-Include-Trybots: luci.chromium.try:linux_chromium_chromeos_msan_rel_ng
Change-Id: I4631a2b1630ce6d37b863e3ec0aebc635c6179c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3691982
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Austin Sullivan <asully@chromium.org>
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1016742}
This replaces DISALLOW_COPY_AND_ASSIGN with explicit constructor deletes
where a local script is able to detect its insertion place (~Foo() is
public => insert before this line).
This is incomplete as not all classes have a public ~Foo() declared, so
not all DISALLOW_COPY_AND_ASSIGN occurrences are replaced.
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: Iea478401b7580682c7b9f195f7af9cbbdb6ce315
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3167292
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#923194}
We added an optional callback to ExtensionService::UninstallExtension()
in order to be informed about when the extension data is safely deleted
(ExtensionService::UninstallExtensionOnFileThread() and
DataDeleter::StartDeleting()).
This is part of a bigger effort to create a data clean-up mechanism for
Chrome apps/extensions. Since Chrome apps/extensions don’t have a
built-in “reset” operation, we uninstall them to fully clear their state
(thus we need to wait for the data to be completely deleted) and
reinstall them back.
More details can be found here: go/imprivata-extension-data-cleanup
Bug: b:186737187
Change-Id: I49ef81af3b5573169ac681c137b3a00798817899
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3109967
Commit-Queue: Maria Petrisor <mpetrisor@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Reviewed-by: Alexander Hendrich <hendrich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#917859}
This reverts commit e16ff9f100.
Reason for revert: Bot was still red after revert: https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Leak/15944
Original change's description:
> Revert "Add StoragePartitionConfig class."
>
> This reverts commit 225f6f4c82.
>
> Reason for revert: I think this is causing failures in:
> virtual/omt-worker-fetch/external/wpt/workers/modules/dedicated-worker-import.any.worker.html
> http/tests/workers/worker-usecounter.html
> virtual/omt-worker-fetch/http/tests/workers/worker-usecounter.html
> and the "webkit_lint" step.
> See example failure: https://ci.chromium.org/p/chromium/builders/ci/Win10%20Tests%20x64/47132
>
> Original change's description:
> > Add StoragePartitionConfig class.
> >
> > Introducing StoragePartitionConfig to make it easier for code to
> > directly request the StoragePartition they need instead of having to
> > go through the indirection of site URLs. Grouping the 3 attributes of
> > a config into a class also makes several call sites simpler. This is
> > being done as part of an effort to reduce the amount of code that
> > depends on site URLs.
> >
> > - Created class for storing the storage partition
> > <domain, name, in_memory> tuple.
> > - Update GetStoragePartitionConfigForSite() and related code to use
> > this new class.
> > - Create BrowserContest::GetStoragePartition() method that takes
> > StoragePartitionConfig as a parameter so future callers do not need
> > to construct a site URL to get a storage partition.
> > - Remove StoragePartitionImplMap::StoragePartitionConfig struct and
> > convert StoragePartitionImplMap to use the new StoragePartitionConfig
> > class.
> >
> > Bug: 1085275
> > Change-Id: I6679ee79ce88cf7cbfdfeb2686452d0cfcc1a9c3
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2253240
> > Commit-Queue: Aaron Colwell <acolwell@chromium.org>
> > Reviewed-by: Aaron Colwell <acolwell@chromium.org>
> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> > Reviewed-by: James MacLean <wjmaclean@chromium.org>
> > Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
> > Auto-Submit: Aaron Colwell <acolwell@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#781691}
>
> TBR=acolwell@chromium.org,alexmos@chromium.org,karandeepb@chromium.org,wjmaclean@chromium.org
>
> Change-Id: Iec47df87cb66a779d2d569e825c9b4ecccf1f2ef
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 1085275
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2263216
> Reviewed-by: Bret Sepulveda <bsep@chromium.org>
> Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#781798}
TBR=acolwell@chromium.org,alexmos@chromium.org,bsep@chromium.org,karandeepb@chromium.org,wjmaclean@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: 1085275
Change-Id: I6eaf4a96de9e08f93e450f708cf6eea5c33ec5b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2264292
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781864}
This reverts commit 225f6f4c82.
Reason for revert: I think this is causing failures in:
virtual/omt-worker-fetch/external/wpt/workers/modules/dedicated-worker-import.any.worker.html
http/tests/workers/worker-usecounter.html
virtual/omt-worker-fetch/http/tests/workers/worker-usecounter.html
and the "webkit_lint" step.
See example failure: https://ci.chromium.org/p/chromium/builders/ci/Win10%20Tests%20x64/47132
Original change's description:
> Add StoragePartitionConfig class.
>
> Introducing StoragePartitionConfig to make it easier for code to
> directly request the StoragePartition they need instead of having to
> go through the indirection of site URLs. Grouping the 3 attributes of
> a config into a class also makes several call sites simpler. This is
> being done as part of an effort to reduce the amount of code that
> depends on site URLs.
>
> - Created class for storing the storage partition
> <domain, name, in_memory> tuple.
> - Update GetStoragePartitionConfigForSite() and related code to use
> this new class.
> - Create BrowserContest::GetStoragePartition() method that takes
> StoragePartitionConfig as a parameter so future callers do not need
> to construct a site URL to get a storage partition.
> - Remove StoragePartitionImplMap::StoragePartitionConfig struct and
> convert StoragePartitionImplMap to use the new StoragePartitionConfig
> class.
>
> Bug: 1085275
> Change-Id: I6679ee79ce88cf7cbfdfeb2686452d0cfcc1a9c3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2253240
> Commit-Queue: Aaron Colwell <acolwell@chromium.org>
> Reviewed-by: Aaron Colwell <acolwell@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Reviewed-by: James MacLean <wjmaclean@chromium.org>
> Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
> Auto-Submit: Aaron Colwell <acolwell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#781691}
TBR=acolwell@chromium.org,alexmos@chromium.org,karandeepb@chromium.org,wjmaclean@chromium.org
Change-Id: Iec47df87cb66a779d2d569e825c9b4ecccf1f2ef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1085275
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2263216
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781798}
Introducing StoragePartitionConfig to make it easier for code to
directly request the StoragePartition they need instead of having to
go through the indirection of site URLs. Grouping the 3 attributes of
a config into a class also makes several call sites simpler. This is
being done as part of an effort to reduce the amount of code that
depends on site URLs.
- Created class for storing the storage partition
<domain, name, in_memory> tuple.
- Update GetStoragePartitionConfigForSite() and related code to use
this new class.
- Create BrowserContest::GetStoragePartition() method that takes
StoragePartitionConfig as a parameter so future callers do not need
to construct a site URL to get a storage partition.
- Remove StoragePartitionImplMap::StoragePartitionConfig struct and
convert StoragePartitionImplMap to use the new StoragePartitionConfig
class.
Bug: 1085275
Change-Id: I6679ee79ce88cf7cbfdfeb2686452d0cfcc1a9c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2253240
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Auto-Submit: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781691}
During another change/need to iterate over all storage
partitions it was noticed that other places in Chromium
have the same requirement. This change exposts a
GetStoragePartitionCount method off of
having to iterate over the collection of partitions to
achieve the same result. In addition the existing call
site of this method has been updated to call the
BrowserContext version.
content: :BrowserContext in order to avoid other classes
Change-Id: Ie60b726841f6955f7df5128cbe89955ea0e3a98d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2057808
Commit-Queue: Brandon Maslen <brandm@microsoft.com>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#742810}
Instead check several conditions earlier to avoid getting (and thus creating)
StoragePartitions that are never used. Also adds a new parameter to
BrowserContext::GetStoragePartition to allow checking existence without
creating the StoragePartition.
Finally remove the hack in BackgroundFetchContext which preserved a
scoped_refptr to URLRequestContextGetter to ensure it was deleted on the UI
thread, now that the StoragePartition is not created and so won't create it.
Bug: 762960
Change-Id: I57055c19f485be706485477125d1434e5ae99181
Reviewed-on: https://chromium-review.googlesource.com/654874
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501226}
This patch was automatically generated by applying clang fixit hints
generated by the plugin to the source tree.
BUG=417463
TBR=sky@chromium.org
Review URL: https://codereview.chromium.org/667943003
Cr-Commit-Position: refs/heads/master@{#300469}
Protect |active_paths| from garbage collection even when they are not direct subdirectories of |storage_root|.
BUG=328637
Review URL: https://codereview.chromium.org/314293003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275662 0039d316-1c4b-4281-b951-d872f2087c98
Reverted due to crashes under memory tools.
BUG=280138
> Remove the Extensions URLRequestContext.
>
> Though chrome-extension: scheme URLs support cookies, they do not share
> a namespace with http: and https:. In particular, chrome-extension://a and
> http://a should not have the same set of cookies.
>
> To enforce this, previously the code created a completely separate
> URLRequestContext for servicing chrome-extension: schemes. However,
> the code really only used this object as a method for conveying the
> correct cookie jar from Profile creation to a few spots where cookies
> were accessed; the rest of the URLRequestContext functionality was unused.
>
> This CL removes the Extensions URLRequestContext code and replaces it
> with APIs that directly expose the needed net::CookieStore.
>
> Lastly, CookieMonster::EnableFileScheme() is removed and
> CookieMonster::Delegate is renamed CookieMonsterDelegate.
>
> EnableFileScheme is an inherently racy API because
> CookieMonsters are creatable on all threads and this
> function sets an unprotected global flag. CookieMonsterDelegate
> is preferable to the nested interface because it can now be
> forward declared.
>
> TBRing darin and sky to cover the rest of the mechanical unittest changes.
>
> TBR=darin,sky
> BUG=158386,159193,57884
>
> Review URL: https://chromiumcodereview.appspot.com/12546016TBR=ajwong@chromium.org
Review URL: https://codereview.chromium.org/23551005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@219787 0039d316-1c4b-4281-b951-d872f2087c98
Though chrome-extension: scheme URLs support cookies, they do not share
a namespace with http: and https:. In particular, chrome-extension://a and
http://a should not have the same set of cookies.
To enforce this, previously the code created a completely separate
URLRequestContext for servicing chrome-extension: schemes. However,
the code really only used this object as a method for conveying the
correct cookie jar from Profile creation to a few spots where cookies
were accessed; the rest of the URLRequestContext functionality was unused.
This CL removes the Extensions URLRequestContext code and replaces it
with APIs that directly expose the needed net::CookieStore.
Lastly, CookieMonster::EnableFileScheme() is removed and
CookieMonster::Delegate is renamed CookieMonsterDelegate.
EnableFileScheme is an inherently racy API because
CookieMonsters are creatable on all threads and this
function sets an unprotected global flag. CookieMonsterDelegate
is preferable to the nested interface because it can now be
forward declared.
TBRing darin and sky to cover the rest of the mechanical unittest changes.
TBR=darin,sky
BUG=158386,159193,57884
Review URL: https://chromiumcodereview.appspot.com/12546016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@219709 0039d316-1c4b-4281-b951-d872f2087c98
This updates headers that forward-declare it and a few random places to use the namespace explicitly. There us a using declaration in file_path.h that makes the rest compile, which we can do in future passes.
Review URL: https://codereview.chromium.org/12163003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180245 0039d316-1c4b-4281-b951-d872f2087c98
On the uninstall of an extension with isolated storage, we want to delete
all the data for the extension from disk as soon as possible. Because we
cannot know when various objects with state on disk
(eg., FileSystemContext) have all been deleted, we do a best-effort delete
for any directory that we know isn't being used.
The way this gets projected into the content modulue is that each extension
defines one partition_domain. If an extension has a <webview> tag, it will
also have multiple StoragePartitions, each with a different partition_name.
If it doesn't have a <webview> tag, the partition_name is considered empty
which yields the default partition. The default partition, and all webview
partitions are peers inside the partition_domain's root directory.
This CL introduces a function that allows us to delete partiton domain.
Special care is taken to not accidentally instantiate a StoragePartition for
the domain if none current exists. This is necessary to allow us to actually
delete the whole partition domain directory.
(Patch by ajwong@chromium.org)
BUG=85127
Review URL: https://chromiumcodereview.appspot.com/11280030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168405 0039d316-1c4b-4281-b951-d872f2087c98
This intentionally doesn't change the ChromeOS behavior at all. They all still use the default FileSystemContext.
This code also exposes the normal and media URLRequestGetters via the StoragePartition, and cleans up a bit of code that was accessing the URLRequestGetter in odd ways. Also, it makes Workers correctly use the Media Cache for Media fetches.
TBR=benjhyden,sky,davemoore,piman,mkwst,kalman
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10909182
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157284 0039d316-1c4b-4281-b951-d872f2087c98
The new layout is
(1) ProfileDir/Default/Storage Partitions/extensions/{ extension_id }/default/
(2) ProfileDir/Default/Storage Partitions/extensions/{ extension_id }/{ hash(BrowserTag.partition) }/
In the future, after we add support for browser tags in webui or add support for server
administrators of websites to opt into storage isolation, we will also need:
(3) ProfileDir/Default/Storage Partitions/origins/{ hash(origin) }/default/
(4) ProfileDir/Default/Storage Partitions/origins/{ hash(origin) }/{ hash(BrowserTag.partition) }/
TBR=willchan
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10913265
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157039 0039d316-1c4b-4281-b951-d872f2087c98
* Get rid of BrowserContext::GetAppCacheService and ResourceContext::GetAppCacheService as they've been replace by accessors on the StoragePartition and WorkerStoragePartition classes.
* Added a BrowsingContext::GetRequestContextForStoragePartition(id) accessor so the constellation of storage context + main request context can initialized properly. Implemented that method in chrome's Profile class in terms of the existing GetRequestContextForIsolatedApp(id) accessor.
* Hold references to the ChromeAppCacheService and ChromeBlobStorageContext inside of ResourceMessageFilter and provide accessors to them. These are for use by the ResourceDispatcherHost singleton which would otherwise not have enough context to get needed references to partitioned things.
* Widen the ResourceDispatcherHostDelegate::RequestBeginning method to also take an AppCacheService* parameter since that value can no longer be retrieved via the ResourceContext. Chrome's impl of this delegate interface needs that value to construct OfflineResourceThrottles.
* Poke at WorkerProcessHost to create ResourceMessageFilters and others to utlize the correct URLRequestContext so the right set of cookies are used in shared workers.
TBR=mihaip,sail,thakis
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10916132
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156991 0039d316-1c4b-4281-b951-d872f2087c98
Eventually all the storage context accessors will be removed from BrowserContext. Instead, users should retrieve the storage context from the StoragePartition.
This also changes RenderProcessHost to take in a StoragePartition removing the need for a re-lookup its storage contexts.
BUG=85121,143486
Review URL: https://chromiumcodereview.appspot.com/10837230
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@152251 0039d316-1c4b-4281-b951-d872f2087c98
