There is a typo in the summary, its CHILD LOCK.

Thanks for the clear report and the excellent demonstration video! 

From a security point-of-view, profile switching is not a security boundary (an attacker with physical access to the PC could just grovel the filesystem to steal state from other profiles) but this certainly looks like a functionality bug in this feature.

Assigning to component.

I didn't get how it's a functionality bug if the feature works fine but password authentication is not done.(the other bug about clicking on links in third party apps,and link doesn't open is surely a functionality bug, but not the bug about notification links.It works as expected but authentication is not done) If people are locking their profile, means they want total security/privacy about their session from strangers,family and friends.

The purpose of this functionality is to protect profile privacy from family,children(child lock),supervised users or friends and not from strangers which is not 100 % achieved due to this bug.Its not about the attacker stealing state or password.Its about protecting user's profile history,passwords from their own friends,family and children or supervised users.

As per your explanation in the comment you mean to say for eg. if someone finds a way to unlock android screen pattern lock, google will say no its not a security bug,its a functionality bug because it allows the attacker to access information in the phone if he has the access to the phone.Is it so.The phone screen lock is meant protect the access to phone,and so the child lock feature to protect access to profiles.

Google markets the feature saying "block account access to supervised users" https://support.google.com/chrome/answer/3463947?hl=en which is not achieved due to this bug and you say its not a security bug.I lock my profile every time at home or office to protect my privacy and same with many people.
I can't tolerate that some bug allows peolpe to access my profile though child locked when google says no one will have access to it if you child lock.Thats why spent some time to report the bug so people can be safe.

You should surely reconsider this!!

> If people are locking their profile, means they want 
> total security/privacy about their session from strangers,
> family and friends.

As explicitly noted in https://support.google.com/chrome/answer/3463947?hl=en

"We recommend sharing your computer only with people you trust. "Exit and childlock" helps protect your privacy, but childlock is not a strong security measure against strangers."

>I didn't get how it's a functionality bug if the feature
> works fine but password authentication is not done.

It's a functionality bug because the feature *does not* work as expected, because, as you've noted, password prompting is expected but isn't happening when the user responds to a notification.

The reason it is not a security bug is that the Child Lock is not a security boundary; in Windows, the Windows Login User Account is the security boundary. An attacker running code within a single Windows Login User Account has many different ways to steal any data to which your account has access. 

If you wish to securely share your device with a determined attacker, the only way to do so is to have them login to Windows using a different account (e.g. Guest).

> I lock my profile every time at home or office to protect my privacy

The proper mechanism for doing so is using a password on your Windows user account and locking your PC using the Windows mechanism for doing so (e.g. hit WindowsKey+L).

> ... you mean to say ... android screen pattern lock ...

No, Android is not Windows. Logging into a Android or Chromebook Device is akin to a Windows User Account Login; it is deemed a security boundary. 

+ treib

@treib: Shall we take a look? I admittedly don't know much about the "new profile management system". But I saw that it is available for years now. Not sure if this will ever launch and if it's worth fixing this issue.

The "new profile management" has been launched for a while - changing that flag from "default" to "enabled" shouldn't actually change anything anymore.

Adding some folks who worked on this, and who might know how hard it'd be to fix this.

+mahmadi who works on the new user manager

Is this a correct characterization of the bug: when you have locked a profile via "Exit and childlock," you can still open the profile without a re-auth by clicking a link from an external app or clicking on a desktop notification?

mahmadi@ - can you check this out? Are you able to repro?

As with the other non-core functions that need to be blocked for Locked Profiles (such as, for example, the App Launcher) has to be implemented in the feature's code. (so in this case, in the notification code's display of the notification)

It's necessary to find the Profile the notification is for, or at least its path. profile_window.h offers a namespaced function IsProfileLocked() which should be checked before showing the notification.

Yeah ,If 2 profiles are created and both have enabled the notifications from the same website or different website,chrome can't decide if the notification is from which profile account and opens the link in admin/main profile, though the notification is from the other profile's website.

#8 - ok, you're basically saying this change needs to be made at the desktop notifications code level, not the user manager code level, correct?

What about clicking external links? How can we handle that? If anything, that seems more concerning to me than desktop notifications.

Re: ewald@ #10 - yes, change should be made at desktop notifications. We should not even be showing the notification if the Profile is locked. 

Although there should be checks in the Profile opening process (various code in profile_window or startup_browser_creator) that ensure that, even if some UI surface tried to open a Browser window for a Profile that's locked, we re-direct to the user manager.

Ah I see, I misread the description. I thought clicking an external link opened the profile directly (circumventing child lock). The bug with external links is that the link doesn't actually carry through and open in the profile after you re-auth in the user manager. So that's a separate bug (filed Issue 651855 to track).

+rpop@ do you know who owns the desktop notifications code?

I believe it's peter@ and owencm@.

>Although there should be checks in the Profile opening process
>(various code in profile_window or startup_browser_creator) that
>ensure that, even if some UI surface tried to open a Browser window
>for a Profile that's locked, we re-direct to the user manager.

Should that get its own bug too? As shown at 3:54 in the demo video, when the user clicks the notification, they do appear to be logged into the locked profile.

We've put this on the list for Q4 — is there a particular release that this would be important for from a product PoV?

My gut feel is that we need a notification blocker that queues notifications when the profile they're being shown for is locked.

I'll caution you that very, very few users use Profile Lock, as it's gated on Supervised Users which are not widely used. You can look in UMA for the Profile.LockedProfilesDuration metric, but I'll give you a hint: it's a very small number.

Take that into account when determining how much to invest in your solution.

Child accounts should launch soon though, which will probably increase the usage of profile lock.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Issue 714402 has been merged into this issue.

 Issue 738934  has been merged into this issue.

Issue 752090 has been merged into this issue.

This security hole opens the supervising profile without a password, even when locked, for notifications originating from a supervised profile.  

See the forum discussion: https://productforums.google.com/forum/#!topic/chrome/aSPZCe22jGI

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot