ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #06831
Re: Sharing dynamic informations between the user session and the greeter
On Mon, Mar 10, 2014 at 7:51 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>wrote:
> Sorry, I was using "greeter" too loosely as a synonym for "login
> screen", i.e. the screen that lets you choose between multiple accounts.
>
> Ubuntu on a phone currently does not use a login screen, because there
> are never multiple user accounts to choose from. Instead, when starting
> the phone, you go directly to the lock screen (a.k.a. "welcome
> screen") for the only account.
>
Eventually we want to allow users to have encrypted home directories on the
phone. (Which is currently blocked by this very same problem of not having
a proper greeter.) With encrypted home directories, we have to have a
login screen for the user must enter a password/pin.
On multi-user devices, the login screen and lock screen might end up
> being implemented by the same code, but whether they should be is part
> of the question in the first place.
Lockscreens are problematic from a security perspective, due to technical
details. Running the PAM stack as a user (i.e. being a PAM "server") has
never worked quite like we want. In order to work when run as a user, PAM
modules (like fingerprint, ldap, or pin) have to run separate daemons as
root to talk to, which doesn't usually thrill the security team. And the
pin module we're planning to use for the phone doesn't work in a user
context (i.e. it doesn't use a root daemon; could add one, but 4-digit pins
would probably be pretty easy for a user to brute-force programmatically
then).
We've been wanting to move away from the user-run lockscreen for quite some
time.
> And why not allow Touch apps on the greeter? Imagine the first
> > boot (with an encrypted home, so we can't auto-login). Why should
> > that behave much differently in terms of whether the user can take
> > photos or not?
> >
> > ...
>
> Whose photo library would the photos end up in? You can't assume they
> should migrate to the account of whoever logs in next; that next login
> might be your grandmother several days later.
That actually was the current design yeah. I mean, it's an awkward
situation regardless. It's hard to know who's holding a multi-user phone
when it's locked. Maybe we can use facial recognition. :)
-mt
Follow ups
References