[enhancement] Trusted Session surface management (required for appstore app trust model), modal subwindows

Bug #1230091 reported by Alberto Mardegan
58
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Mir
Triaged
Medium
Unassigned
content-hub
Invalid
Undecided
Unassigned
unity-mir
Triaged
High
Unassigned
mir (Ubuntu)
Triaged
Medium
Unassigned
signon (Ubuntu)
Invalid
Undecided
Unassigned
unity-mir (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

(I'm filing this as a bug in order to be able to point other people to it, and to track its progress; if there's a blueprint containing this task, please let me know)

Some components (such as the Online Accounts trusted helper) need to be able to pop-up a window (typically, a dialog) on top of the running application. Such windows should be modal to the application, that is the user should not be able to interact with the application while the modal window is displayed on top of them. This also means that in the task switcher one shouldn't see two windows, but only the topmost modal window (and parts of the application window, in case the modal window on top is a non-fullscreen dialog).

For developers, this API already exists in Qt: http://doc.qt.io/qt-5/qwindow.html#fromWinId
It needs to be implemented in the QPA plugin, so feel free to add the relevant projects to the bug report.

From jdstrand>
This is a hard requirement for application confinement because of our trust model-- permission to access sensitive data by AppStore apps is typically granted or denied at the time of access (caching the result for later use as appropriate), so users have a context for the access being requested. We do this instead of throwing up a permissions prompt at installation. However, for it to work, trusted helpers like online accounts and location require this functionality from unity-mir. A trust-store is also being implemented so other services like calendar and contacts can do the same. Because this feature is not implemented, the implementation for online accounts, location and the trust-store is blocked and appstore apps are therefore able to access these services without the user knowing.

Tags: enhancement
description: updated
tags: added: application-confinement
Changed in unity-mir (Ubuntu Saucy):
importance: Undecided → High
description: updated
summary: - [feature] Window reparenting
+ [feature] Window reparenting (required for appstore app trust model)
Revision history for this message
Gerry Boland (gerboland) wrote : Re: [feature] Window reparenting (required for appstore app trust model)

Thoughts:

1. Mir has no concept of window parent/child relationships, for now it just has a list of windows per application. This needs to be added, as shell will need that information.

2. Do we want any application to be able to reparent its window to another applications window? Probably not, so need a way to authorize these re-parent moves. Apps like the trusted helpers should always be able to do it. Also I see no reason why if app1 spawns app2, then app2 should be able to reparent a window to app1's window.

3. On the Mir client side API, apps need a way to fetch an identifier of the window it wants its window to be a child of. This information only exists in the mir server currently. Then need to add API to request the reparenting.

Talking with the Mir team about this last week, the idea of "parent/child" relationship for applications was floated. This is where an application can be designated a child of another. So if app1 is child of app2, then if app1 creates a window, it is automatically made a child of app2's window (and is given focus). Or even has choice of app2's windows to be reparented to.

This would make application lifecycle work easier, as can easily tell which children apps to suspend/resume with the parent. And would mean only 1 window in task switcher. And would prevent arbitrary reparenting of windows by abusive applications.

However how does one designate one application to be child of another? I need Mir guys to answer this.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity-mir (Ubuntu):
status: New → Confirmed
Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Gerry, your suggested solution wouldn't work for us: we need to decouple the process child-parent relationship from the windows' one. We pop up windows from D-Bus services, and the same process could be serving multiple modal windows on top of different client applications (see also bug #1223881).
I also recommend that processes which create windows on top of other processes be never stopped. In fact, I think that the shell should treat them as transparent: when in the task switcher, the user should continue seeing the name of the started application, not of the process who created the topmost window.

I really recommend to stick to the Qt API, and if needed protect the API with apparmor. Since apparmor can protect files, and not individual method calls, we could make it so that the QPA (or mir-client) implementation of the reparenting request first attempts to create a file $XDG_RUNTIME_DIR/ubuntu-api/<appId>/window_reparenting, and protect this path behind an apparmor rule, so that only apps belonging to the "window_reparenting" policy group can successfully create the file. Or we could simplify things and simply not allow any third-party apps to use the window reparenting feature (in fact, I can hardly think of a case where it would be useful for ordinary apps). Then, the shell (or mir-server) code would effectively reparent the windows only if that file is present.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It's true Mir does not implement "parenting" of any sort. I think this was intentional.

The use case of modal dialogs is a good case for parenting, but if that remains the only use case I think we should pause to consider if there are any better alternatives. "Parenting" is otherwise not required in Mir so we should only consider adding it if absolutely necessary.

Revision history for this message
kevin gunn (kgunn72) wrote :

strong desire, but not required for phone v1

Changed in mir:
importance: Undecided → High
status: New → Triaged
Changed in unity-mir:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Adding a signon task since it will need to be adjusted to use this Mir feature.

Changed in signon (Ubuntu Saucy):
importance: Undecided → High
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Adding an apparmor-easyprof-ubuntu task since because of this bug, the accounts policy group is reserved and not available to untrusted appstore apps. When mir and online accounts are fixed, we can move the accounts policy group back to 'common'.

Revision history for this message
Rasmus Eneman (pie-or-paj) wrote :

>In fact, I can hardly think of a case where it would be useful for ordinary apps
There are some use cases (for examples Facebooks "Chat Heads" on Android)
but nothing that can't wait.

I'm not following you on the display server implementation details. I just
states that there are use cases where ordinary third-party apps would need to
display windows over other apps.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

On desktop there's a solid example of reparenting -- plugin windows in a browser. Those subwindows (like Flash) are rendered by an external process. Although supporting Flash going forward is probably not important at all. And we need the browsers themselves to support Mir first.

Some kind of parent-child relationship will indeed be required to implement modal dialogs at least.

Changed in apparmor-easyprof-ubuntu (Ubuntu Saucy):
status: New → Won't Fix
no longer affects: apparmor-easyprof-ubuntu (Ubuntu)
no longer affects: apparmor-easyprof-ubuntu (Ubuntu Saucy)
no longer affects: apparmor-easyprof-ubuntu (Ubuntu T-series)
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: New → Confirmed
tags: added: feature
summary: - [feature] Window reparenting (required for appstore app trust model)
+ [enhancement] Window reparenting (required for appstore app trust model)
tags: added: enhancement
removed: feature
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: [enhancement] Window reparenting (required for appstore app trust model)

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in signon (Ubuntu):
status: New → Confirmed
Changed in signon (Ubuntu Saucy):
status: Confirmed → Won't Fix
Changed in signon (Ubuntu Trusty):
importance: Undecided → High
Changed in unity-mir (Ubuntu Trusty):
importance: Undecided → High
Changed in unity-mir (Ubuntu Saucy):
status: Confirmed → Won't Fix
Changed in mir:
assignee: nobody → rosa maria (rprosamaria383)
Changed in mir:
assignee: rosa maria (rprosamaria383) → nobody
Changed in unity-mir:
assignee: nobody → rosa maria (rprosamaria383)
Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: nobody → rosa maria (rprosamaria383)
Michał Sawicz (saviq)
Changed in unity-mir:
assignee: rosa maria (rprosamaria383) → nobody
Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: rosa maria (rprosamaria383) → nobody
Revision history for this message
kevin gunn (kgunn72) wrote :

lowering for mir, as for the near future window reparenting isn't needed. all the surface management can be done in shell.

Changed in mir:
importance: High → Medium
summary: - [enhancement] Window reparenting (required for appstore app trust model)
+ [enhancement] Trusted Session surface management (required for appstore
+ app trust model)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Just extended the title a little, or else I know we'll never find this bug again :)

summary: [enhancement] Trusted Session surface management (required for appstore
- app trust model)
+ app trust model), modal subwindows
Revision history for this message
Daniel Holbach (dholbach) wrote :

Right now we can't accept apps in the store which use the "accounts" security policy group until this bug is fixed. Is this bugs in the priority list?

rosa maria (ceryscloe)
Changed in mir:
assignee: nobody → rosa maria (ceryscloe)
Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: nobody → rosa maria (ceryscloe)
Changed in signon (Ubuntu Trusty):
assignee: nobody → rosa maria (ceryscloe)
Changed in unity-mir (Ubuntu Saucy):
assignee: nobody → rosa maria (ceryscloe)
Changed in mir:
assignee: rosa maria (ceryscloe) → nobody
Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: rosa maria (ceryscloe) → nobody
Changed in signon (Ubuntu Trusty):
assignee: rosa maria (ceryscloe) → nobody
Changed in unity-mir (Ubuntu Saucy):
assignee: rosa maria (ceryscloe) → nobody
Bill Filler (bfiller)
Changed in content-hub:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
CSRedRat (csredrat) wrote :
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Removing suayc and trusty tasks since we won't fix those and they are cluttering the reports. Adjusting the Ubuntu tasks to Critical since online accounts use of trust sessions is an rtm requirement.

no longer affects: unity-mir (Ubuntu Saucy)
no longer affects: unity-mir (Ubuntu Trusty)
no longer affects: signon (Ubuntu Trusty)
no longer affects: signon (Ubuntu Saucy)
Changed in apparmor-easyprof-ubuntu (Ubuntu):
importance: Undecided → Critical
Changed in signon (Ubuntu):
importance: High → Critical
Changed in unity-mir (Ubuntu):
importance: High → Critical
tags: added: rtm14
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

If there is another bug that should be used for Mir trust session support and online accounts use of it for rtm, please let me know. For now, adding rtm14 tag.

Changed in mir:
milestone: none → 0.7.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This is a major enhancement that won't happen in RTM (or possibly even utopic). I suspect you have attached tag "rtm14" to the wrong "trust sessions" bug.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

What is that bug?

Changed in mir:
milestone: 0.7.0 → none
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I didn't here back on the bug, however, online accounts and trust-store now have sufficient Mir support to utilize trust sessions, and we can therefore remove the rtm14 tag and likely reduce the severity. I will take care of the Ubuntu tasks.

tags: removed: application-confinement rtm14
no longer affects: apparmor-easyprof-ubuntu (Ubuntu)
Changed in signon (Ubuntu):
status: Confirmed → Invalid
Changed in content-hub:
status: Triaged → Invalid
Changed in signon (Ubuntu):
importance: Critical → Undecided
Changed in content-hub:
importance: Medium → Undecided
Changed in unity-mir (Ubuntu):
importance: Critical → Undecided
Revision history for this message
Alberto Mardegan (mardy) wrote :

Trusted sessions are working rather well now. The only problem left is supporting more than one trust session at the same time. Do you have any update on that?
With more apps starting to use trust sessions (apps using Online Accounts and Content Hub), supporting more than one session at a time is becoming more important.

Jane (jsearle00)
Changed in unity-mir:
status: Triaged → Fix Committed
Changed in mir:
status: Triaged → Fix Committed
Changed in mir:
status: Fix Committed → Triaged
Changed in unity-mir:
status: Fix Committed → Triaged
description: updated
Revision history for this message
Matthew Paul Thomas (mpt) wrote :
Changed in unity-mir (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

(I now realize that this bug report is about Mir allowing out-of-process child windows in general, not about the permissions prompt in particular. Sorry for the noise.)

Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.