Provide persistent data sharing folder for greeters

[Michael Terry]

So there are a few features in Ubuntu Touch that want persistent storage that is only read/write-able by the greeter and the user. Like:

* Contact photos for incoming calls (shared by telephony-service for the greeter to display on incoming call).
* Screenshots of the home screen (not needed yet, but might be done for showing what login will look like for encrypted home directories before we log in for the first time and have access to the session).
* User data like photos taken when the greeter is open, but then pushed to user session once the user is logged in.

So these could all be fixed if LightDM did the following:

* mkdir -p /var/lib/lightdm/users
* chmod o+x /var/lib/lightdm /var/lib/lightdm/users
* for each visible user:
  * mkdir -p /var/lib/lightdm/users/$UID
  * chown $USER:lightdm /var/lib/lightdm/users/$UID
  * chmod 770 /var/lib/lightdm/users/$UID

i.e. this is basically a persistent /run/user shared with the lightdm user (or whichever user is set as the greeter user; I recall that is configurable).

The greeter can't set something like this up, because it doesn't have permission to chown anything that could be shared with the user (it's not in any of the user's groups). And we don't want these folders to be world-readable.

Is this something you would support? If so, I can start on a patch. I just wanted to discuss approaches first.

[Robert Ancell (robert-ancell)]

Short answer - yes, this seems like a useful feature.

Thoughts:
- Obviously this sound like something that ideally accounts service would provide. But a-s seems to be only for public information and this is private to two parties, one of which is a bit lightdm specific so fitting it into LightDM instead seems a lot easier. Also, a-s doesn't seem to be universally adopted so nice to not depend on more complex a-s behaviour
- Having an unstructured data storage that lasts forever makes me a little uneasy (see more below)
- We need to be careful not to collect crap in these directories, either by having directories for users who no longer exist or files that have been forgotten about - perhaps we could consider putting an expiry on each file somehow?
- We need to support multiple greeters/sessions writing to this directory - some sort of defined directory structure like "com.canonical.unity-greeter/photos/*"?
- Events via the filesystem is racy. It would be nice to have some sort of notification system to synchronise this (no easy solution comes to mind).
- From the greeter side we should consider some helper functions into liblightdm to encourage correct usage. From the session side it's a bit harder.

[Michael Terry (mterry)]

> Obviously this sound like something that ideally accounts service would provide. But a-s seems to be only for public information and this is private to two parties, one of which is a bit lightdm specific so fitting it into LightDM instead seems a lot easier. Also, a-s doesn't seem to be universally adopted so nice to not depend on more complex a-s behaviour

Yes... I was thinking of this as more naturally being a LightDM feature, not an AS one.

> We need to support multiple greeters/sessions writing to this directory - some sort of defined directory structure like "com.canonical.unity-greeter/photos/*"?

Sure. Just like /run/user, anything that writes to it needs to properly namespace things. Package name or reverse URL or whatever. Doesn't really matter, as long as both sides know what's up.

> Events via the filesystem is racy. It would be nice to have some sort of notification system to synchronise this (no easy solution comes to mind).

Not racy in a way we care about, I don't think... I believe all these features I'm thinking of would be one way:
- User pushing contact image to greeter
- User pushing screenshot to greeter
- Greeter pushing camera photos to user

Can you give an example of a racy interaction that might happen?

> We need to be careful not to collect crap in these directories, either by having directories for users who no longer exist or files that have been forgotten about - perhaps we could consider putting an expiry on each file somehow?

This is an interesting problem for sure. Both on creation-of-directory and removal-of-files sides. But I don't think we have to do much.

So on the creation side, we can just create directories on startup for all users in our list. If a user is created during lightdm's lifecycle... We could either watch passwd changes and recheck or if the greeter tries to switch to a user, create the directory then...

For file removal... We have several possibilities:
* User is removed. We can certainly wholesale remove directories at startup for removed users. Same for watching passwd changes above. When we add, we can remove too.
* A program that is active and working normally. It can manage its own files best. It'll remove the ones that it knows aren't needed.
* A program stops using this functionality. It can clean up its cruft itself.
* A program is uninstalled. This seems appropriate for a postrm hook.

> From the greeter side we should consider some helper functions into liblightdm to encourage correct usage. From the session side it's a bit harder.

Sure... I was thinking it'd be as simple as reading and writing files. But if we do end up adding more complicated file-lifecycle rules, it might make sense.

Thoughts?

[Robert Ancell (robert-ancell)]

> Can you give an example of a racy interaction that might happen?

The sort of case I was thinking of is when you have both a greeter and a session open and the greeter makes some changes to the shared space and then has to notify the session. There's no obvious way for the greeter to talk to the session and the greeter might write multiple files in this transaction. We don't want the session to read/delete files from this transaction until it's complete.

To avoid everyone writing different protocols or doing flaky things like inotify to work out the framing for these transactions it would be nice if we could provide something for that.

[Robert Ancell (robert-ancell)]

To clarify, my above thoughts are just what I'd like in a perfect system. I don't know if we'll have good answers to any of these questions so we don't have to block this feature on any of these. I think we should err on the side of simplicty rather than overengineering it.

[Michael Terry (mterry)]

> There's no obvious way for the greeter to talk to the session and the greeter might write multiple files in this transaction

Note that we do have side channels in AccountsService and unity-greeter-session-broadcast we could use for coordination.

OK, sounds like maybe we agree enough to get a first implementation going.