Guest logins, (was Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel))

David Edmundson david at
Wed Aug 29 21:40:34 BST 2012

On Wed, Aug 29, 2012 at 9:17 PM, Thomas Lübking
<thomas.luebking at> wrote:
> Am 29.08.2012, 03:21 Uhr, schrieb Harald Sitter <sitter at>:
>> On Wed, Aug 29, 2012 at 2:59 AM, Thomas Lübking
>> <thomas.luebking at> wrote:
>>> but I'm willing to
>>> be enlightened about the striking advances of this integration.
> Thanks for the link.
> Reads like they're looking for
> useradd -md /tmp/ubuntu-guest ubuntu-guest
> usermod -L ubuntu-guest
> and a guest-session script
> ---- guest-session---
> #!/bin/sh
> if [ $(id -u) != 0 ]; then
>    logger "`whoami` allowed guest session"
>    /usr/lib/kde4/libexec/kscreenlocker --forcelock &
>    sudo/pkexec guest-session
>    logger "`whoami` permitted guest session ended"
>    exit
> fi
> su ubuntu-guest
> export DISPLAY=:1 #todo - not hardcode :1
> X :1 & sleep 1 & ck-launch-session -display :1 startkde #nobody really uses
> unity
> #or so - X does not auto-end in this just written down script.
> /---------
> This is it?
> Brings us to the questioned DM integration requirement.
> The only part remotely suggesting a special integration with a DM seems:
>     "Thus we will extend gdm to allow spawning a new X server for the
> special :guest user (which is not a valid PAM user name and thus cannot
> collide with any real user)."
> What is no way a requirement but a choice.
> There is no reason to control access this way (ie. prevent remote logins on
> that user or whatever - pam_access does that and locked users can't login
> this way at all) and there's no reason to create an invalid PAM user account
> to prevent collisions either (one can pre-allocate one or create one
> guest-<rnd> and check that against /etc/passwd until there's no clash) and,
> actually, prevents two coincident guest logins.
> Just locking the account and sudo/polkit su to it would ensure to only allow
> such authenticated "login".
> So maybe i'm just stupid, but my question frankly remains:
> why should one turn the DM into an AM to add a locked down guest account, if
> the same can be achieved by a mini script and maybe a polkit rule?
> The functionality can be provided aside the DM for those who really want it
> - the particular thing is called "LightDM" and it's not even "only" a DM?
> Cheers,
> Thomas
> -----
> Before mentioned:
> The only aspect are guest logins from the DM as *suggested* by
>     ""An existing user must authenticate the start of a guest session"
> should be optional, so that someone can use the computer without anyone else
> being present."
> What however completely contradicts (the very much true)
>     "This design shouldn't aim for ultimate security. In the use cases, the
> guest users are somewhat trusted and also observed while they work on the
> box. We do not design a solution that can resist half an hour of unobserved
> tampering. In particular, this is not strong enough to be a fully secure
> kiosk solution (which is why we require authentication from an existing
> user)."
> And also invalidates the
>     "Common practice for many people is to create a "guest" user account
> with a trivial or empty or empty password, but this is a potential security
> threat."
> rationale, because one just added a permanent pwdless account (ideally at
> least not for remote logins)

I know I'm the one that started this conversation, but there's little
point discussing the requirements of something Ubuntu wanted on our
mailing lists.

That document is quite old, (it's planning for Intrepid.. I don't know
Ubuntu that well, but we're on "P" now, so it must be several years
old), and in fact refers to when they were planning on changing GDM
(before realising it was a mess, and hard to add). I don't know how
much of that is accurate of what actually happens.

I don't quite understand the point you're trying to make, you propose
how a guest session could work, and it's quite similar to what
actually happens in LightDM. There's quite a few extra complications,
but not a lot.

Can I suggest you send your email to who will be able
to give a better reason for any design decisions.

More information about the kde-core-devel mailing list