Delay in or flaky application of polices from registry |
|||||||
Issue descriptionOn Windows: 1. Register a custom protocol handler. E.g.: [HKEY_CLASSES_ROOT\foobar] "URL Protocol"="" @="URL:foobar protocol" [HKEY_CLASSES_ROOT\foobar\shell] [HKEY_CLASSES_ROOT\foobar\shell\open] [HKEY_CLASSES_ROOT\foobar\shell\open\command] @="notepad.exe \"%1\"" 2. Add a policy registry key to whitelist the scheme. E.g.: [HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome\URLWhitelist] "1"="foobar:*" Open Chrome and visit, say: data:text/html,<a href="foobar:blah">linky</a> Clicking on "linky" at this point *should* open notepad.exe without any prompts. But doesn't :-( Tested on 60.0.3112.101 (Official Build) (64-bit) (cohort: Stable) However, doing the following works: 1. Change something in the Policies\Google\Chrome\URLWhitelist registry subtree. E.g. add "2"="anything.really". 2. Visit chrome:policy and hit "Reload policies" At this point, visiting <a href="foobar:blah">linky<a> and clicking on "linky" will open notepad.exe without a prompt.
,
Sep 5 2017
,
Sep 6 2017
,
Sep 6 2017
This issue is specific to URL black/white listing and is due to the following bit of code in //components/policy/core/browser/url_blacklist_manager.cc:
URLBlacklistManager::URLBlacklistManager(
PrefService* pref_service,
const scoped_refptr<base::SequencedTaskRunner>& background_task_runner,
const scoped_refptr<base::SequencedTaskRunner>& io_task_runner,
OverrideBlacklistCallback override_blacklist)
: pref_service_(pref_service),
background_task_runner_(background_task_runner),
io_task_runner_(io_task_runner),
override_blacklist_(override_blacklist),
ui_task_runner_(base::ThreadTaskRunnerHandle::Get()),
blacklist_(new URLBlacklist),
ui_weak_ptr_factory_(this),
io_weak_ptr_factory_(this) {
pref_change_registrar_.Init(pref_service_);
base::Closure callback = base::Bind(&URLBlacklistManager::ScheduleUpdate,
base::Unretained(this));
pref_change_registrar_.Add(policy_prefs::kUrlBlacklist, callback);
pref_change_registrar_.Add(policy_prefs::kUrlWhitelist, callback);
// Start enforcing the policies without a delay when they are present at
// startup.
if (pref_service_->HasPrefPath(policy_prefs::kUrlBlacklist)) // <<< HERE
Update();
}
The URLWhitelist appears to be originally intended to only be used in the presence of a blacklist. But subsequent use of the whitelist for controlling prompting for external protocol handlers made it reasonable to have a whitelist in the absence of a blacklist.
The code above only initializes the black/whitelists if the URLBlacklist pref is defined at startup. Hence specifying just the whitelist causes the browser to ignore the whitelist unless a change is made later which causes the pref observer to fire.
A temporary workaround would be to specify some sort of blacklist such that the URL policies are correctly initialized at startup. E.g.:
[HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome\URLBlacklist]
"1"="somenonexistentscheme:*"
In the long run, the above code should also check if there's a whitelist defined.
,
Sep 6 2017
Got it-- OK, so we will need to fix this bug but glad the work-around is easy. Thank you
,
Sep 8 2017
Asanka, Can you clarify if this is a broader policy/registry thing or specific to the URLWhitelist and Blacklist policies?
,
Sep 8 2017
It's specific to URLWhitelist/URLBlacklist and doesn't affect other policies.
,
Sep 8 2017
OK, it will remain a P2 in that case.
,
Sep 8 2017
+caitkp who might tackle this next week. Feel free to assign it to yourself if you decide to take it on.
,
Sep 8 2017
https://chromium-review.googlesource.com/c/chromium/src/+/656040
,
Sep 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e82a0fbd333222f60612538aeb402ee3aef63833 commit e82a0fbd333222f60612538aeb402ee3aef63833 Author: Asanka Herath <asanka@chromium.org> Date: Mon Sep 25 20:00:32 2017 Check both the URL whitelist and blacklist upon creation. URLBlacklistManager consults queries its PrefService upon creation to determine whether it should construct a URLBlacklist object. Currently it only checks for the existence of the policy_prefs::kUrlBlacklist pref. However, it is valid for there to be a policy_prefs::kUrlWhitelist policy defined, with no kUrlBlacklist pref. In such a situation, URLBlacklistManager will not construct an initial URLBlacklist. Thus the existing whitelist preference will effectively be ignored until a pref change causes the explicit construction of a URLBlacklist. This change updates the URLBlacklistManager constructor to check for both a whitelist and a blacklist. Bug: 759185 Change-Id: I0c9ab2062f36fb83ee6e538e8007807009d6bfb5 Reviewed-on: https://chromium-review.googlesource.com/656040 Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org> Commit-Queue: Asanka Herath <asanka@chromium.org> Cr-Commit-Position: refs/heads/master@{#504142} [modify] https://crrev.com/e82a0fbd333222f60612538aeb402ee3aef63833/components/policy/core/browser/url_blacklist_manager.cc [modify] https://crrev.com/e82a0fbd333222f60612538aeb402ee3aef63833/components/policy/core/browser/url_blacklist_manager_unittest.cc
,
Sep 26 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by pbond@chromium.org
, Aug 28 2017