disable guest session screen lock using gsettings

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

gdm-guest-session is gone from precise. I assume you chose the guest session in lightdm.

Yes, I used whatever is default in precise. Just didn't know which package provided the functionality...

Lowering the setting and unassigning, so what happens, happened there is that guest-account calls:
" gconftool-2 --set --type bool /desktop/gnome/lockdown/disable_lock_screen True"

or gnome-screensaver migrated to gsettings...

it happens to work because the gconf keys are migrated to gsettings on login, the migration binary was buggy in gconf 2.32.4 (which exposed this bug) and is fixed again in 2.32.5

we should change that for a gsettings,dconf use but desrt recommended to way for dconf changes he added to his todolist to be able to create a db without needing to spawn a session bus, the current works until we do it this way, which should be before the lts

Can you help me understand what the expected behavior is? I presume it is that the screen blanks but that it doesn't lock, is that correct?

Correct

Gary, right. The indicator menu should not have a "lock screen" entry, ctrl+alt+L should do nothing, and when the screen saver kicks in it should just go away again if you press a key.

@seb128: Should that still be happening? Your comment suggests that it shouldn't be the case but my guest session has screen lock active every time I switch to it.

no it shouldn't be happening, what do you get if you run "gsettings gset org.gnome.desktop.screensaver lock-enabled" in the guest session?

$ gsettings get org.gnome.desktop.screensaver lock-enabled
true
$ gsettings set org.gnome.desktop.screensaver lock-enabled false
$ gsettings get org.gnome.desktop.screensaver lock-enabled
false
$ # it reverts back to true after I create a new guest session

can you add .xsession-errors from the guest session to the bug? it's likely gsettings-data-convert which hits an issue due to a buggy schemas and fail to migrate the setting for the user, can you run the command by hand?

It seems that the issue is somehow related to the Apparmor profile, but unfortunately by disabling it and logging in as guest I've fixed it and now, even after I re-enable the profile lock is disabled [1]

I have no idea what the actual error was, although there are quite a few apparmor audit messages when the session is started:

[ 54.554230] type=1400 audit(1334831715.697:30): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2665/cmdline" pid=2660 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 54.554593] type=1400 audit(1334831715.697:31): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2666/cmdline" pid=2660 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 54.555207] type=1400 audit(1334831715.697:32): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2667/cmdline" pid=2660 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 54.555823] type=1400 audit(1334831715.697:33): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2668/cmdline" pid=2660 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 54.560074] type=1400 audit(1334831715.701:34): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2671/cmdline" pid=2660 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 54.580359] type=1400 audit(1334831715.721:35): apparmor="DENIED" operation="mount" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/tmp/guest-1MB45i/.gvfs/" pid=2684 comm="gvfs-fuse-daemo" fstype="fuse.gvfs-fuse-daemon" srcname="gvfs-fuse-daemon" flags="rw, nosuid, nodev"
[ 62.044159] type=1400 audit(1334831729.207:36): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/2575/stat" pid=2819 comm="bamfdaemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0
[ 62.044181] type=1400 audit(1334831729.207:37): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" name="/proc/1473/stat" pid=2819 comm="bamfdaemon" requested_mask="r" denied_mask="r" fsuid=132 ouid=0

but this could be red herring

I'm closing the bug for now, Seb has said that he'll try to reproduce it on the newly installed system from the daily CD, and if he can he'll reopen it. For now I don't see how we can even track it any further.

[1] gsettings get org.gnome.desktop.screensaver lock-enabled returns "true" but the "Lock Screen" menu entry is gone, ctrl+alt+L does nothing and lock related options in the "Lock & Brightness" settings panel are disabled.

I have reproduced this on an up to date precise install.

I've noticed that this bug has been Confirmed although there is not clear indication as to how to recreate this bug. Subsequently, I'm setting its status to Incomplete until that information is provided.

Please kindly provide steps to reproduce the issue.

@Rex:

/usr/sbin/guest-account has
   gconftool-2 --set --type bool /desktop/gnome/lockdown/disable_lock_screen True

that's wrong and should use gsettings

@Rex
See e.g. bug #1063711.

@Sebastien
The screen shouldn't ever be locked in a guest session, should it? (Bug #1022858 is also related, btw.)

but part of a larger series of bugs affecting sane defaults for guest session, e.g., web browser "remember password" prompts are unnecessary, prompts to backup the computer are unnecessary and misleading, etc. there are a few others but they escape my memory at the moment.

all these problems appear to stem from "guest account" using /etc/skel to form a temporary "new user account," yes? whereas a guest account isn't simply a temporary new account to be discarded on exit, it is a specialized restricted account that should have certain settings completely disabled, like screen lock and backup and automatic updates checking, etc.

while i like that guest accounts can be customized from the default using /etc/skel/ i think there is another layer of customization that should be off-limits as it would make no sense (e.g., enabling screen lock). i am unfamiliar with the mechanics of current guest account creation, but maybe someone could manually define the sane guest-session defaults, and then use a script to derive any customizations that don't affect those sane defaults from /etc/skel

thus, the system administrator would get their custom new user accounts, but not at the expense of corrupting sane guest session defaults.

is this worth another bug report to look at overall sane guest-session defaults, or is the issue that there *are* already sane defaults but they aren't being implemented correctly?

@ethanay
Sounds like you would be interested in checking out
https://help.ubuntu.com/community/CustomizeGuestSession
That tutorial addresses some of the things you mention.

I have played with the thought of modifying the lightdm package, making some customization ideas the default for the guest session feature.

this is a great resource, thank you! it is good to see some foundational
material already in existence, people recognizing at least on an initial
level that the default guest session is not sufficient.

would another bug report be appropriate for organizing sane guest session
defaults to be included in Ubuntu for users without the time or ability to
manually customize their guest sessions to behave well?

On Fri, Oct 19, 2012 at 9:01 AM, Gunnar Hjalmarsson <email address hidden>wrote:

> @ethanay
> Sounds like you would be interested in checking out
> https://help.ubuntu.com/community/CustomizeGuestSession
> That tutorial addresses some of the things you mention.
>
> I have played with the thought of modifying the lightdm package, making
> some customization ideas the default for the guest session feature.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/951000
>
> Title:
> disable guest session screen lock using gsettings
>
> Status in “lightdm” package in Ubuntu:
> Triaged
>
> Bug description:
> bug # 275768 seems to be back in precise. My guest session is locking,
> when there is no password to unlock.
>
> I switched to the guest session from my admin account.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/951000/+subscriptions
>

On 2012-10-20 08:17, ethanay wrote:
> would another bug report be appropriate for organizing sane guest
> session defaults to be included in Ubuntu

Possibly. But maybe drafting a blueprint, with a whiteboard and specific work items, would be even better. The natural person to approve it would be Robert Ancell, the author of lightdm.

A couple of years ago I filed bug #667089, and comment #3 in that bug report lists a few other guest session related bugs.

> for users without the time or ability to manually customize their
> guest sessions to behave well?

Hey, the tarballs at https://help.ubuntu.com/community/CustomizeGuestSession are really easy to use. ;-) But seriously I agree that much of it - and probably other stuff as well - should be there by default.

Ok, I roped you into this process, too :)

https://blueprints.launchpad.net/ubuntu/+spec/guest-session-sane-defaults

if you can help populate the blueprint? not sure what the whiteboard is or
how to get it started. work items we need to start compiling as soon as we
decide on the strategy. FYI, i am NOT a coder, so any implementation stuff
is faaar beyond me.

On Sat, Oct 20, 2012 at 5:05 PM, Gunnar Hjalmarsson <email address hidden>wrote:

> On 2012-10-20 08:17, ethanay wrote:
> > would another bug report be appropriate for organizing sane guest
> > session defaults to be included in Ubuntu
>
> Possibly. But maybe drafting a blueprint, with a whiteboard and specific
> work items, would be even better. The natural person to approve it would
> be Robert Ancell, the author of lightdm.
>
> A couple of years ago I filed bug #667089, and comment #3 in that bug
> report lists a few other guest session related bugs.
>
> > for users without the time or ability to manually customize their
> > guest sessions to behave well?
>
> Hey, the tarballs at
> https://help.ubuntu.com/community/CustomizeGuestSession are really easy
> to use. ;-) But seriously I agree that much of it - and probably other
> stuff as well - should be there by default.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/951000
>
> Title:
> disable guest session screen lock using gsettings
>
> Status in “lightdm” package in Ubuntu:
> Triaged
>
> Bug description:
> bug # 275768 seems to be back in precise. My guest session is locking,
> when there is no password to unlock.
>
> I switched to the guest session from my admin account.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/951000/+subscriptions
>

On 2012-11-09 04:13, ethanay wrote:
> Ok, I roped you into this process, too :)

That's fine. But I changed the "drafter" to you, and subscribed myself to the blueprint.

> if you can help populate the blueprint? not sure what the whiteboard is or
> how to get it started.

The whiteboard is simply a free form field where we can discuss the need for changes. I suggest that you start by listing the ideas you have. I'll add my ideas afterwards, unless not covered by you.

> FYI, i am NOT a coder, so any implementation stuff
> is faaar beyond me.

If Robert approves it, I'm willing to be the assignee.

a similar issue exists with Kubuntu 12.10. lightdm offers a guest session, but
  * Kickoff's Leave menu offers a Lock action that locks the session, and
  * when the screensaver activates, it locks the session.
in both cases, the lock screen's unlock dialog shows an apparently auto-generated username (e.g. "guest-iW6OvM") and requires a password to unlock the session. as a result, the user is stuck in the lock screen.

the unlock dialog offers a "Switch User..." action, which subsequently offers to "Start New Session". but using this to start a "new" guest session actually just switches to the existing session, which is still locked.

a quick workaround is to restart lightdm from the console (ctrl+alt+f1, log in as an admin user, ``sudo service lightdm restart``). however, the previous guest session is lost as a result, along with any work that was unsaved in it. also, it shouldn't be expected that a guest user has access to an admin account.

glancing over the suggestions in the comments here, it looks like the fix may or may not be specific to the session manager, depending on the chosen approach. i see suggestions that appear to be specific to GNOME (via GSettings); my Kubuntu installation has GSettings, but i have no idea whether/how it is used by Kubuntu.

is it appropriate to address this in this bug, or should i create a new one specifically regarding KDE guest sessions?

there is no X session when guest-account runs that is required by using gsettings command to modify the dconf database.

gsettings doesn't require an X session no...

When the issue happens, I tried to trun gsettings-data-convert --verbose --dry-run, it says
Directory '/usr/share/GCong/gsettings' all uptodate, nothing to do
However, gconftool-2 --get /desktop/gnome/lockdown/disable_lock_screen (true) and gsettings get org.gnome.desktop.lockdown disable-lock-screen are not consistent (false) are not consistent.

I tried adding the gsettings command to /usr/sbin/guest-account and ran it manually, i.e.:

$ sudo /usr/sbin/guest-acccount add

It gives the error:

(process:27140): dconf-CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly.

So the 'su' inside /usr/sbin/guest-account doesn't work in this case. In particular, gsettings is requiring $XDG_RUNTIME_DIR to exist and be set, this doesn't occur until the guest session has logged in.

additional information : gsettings-data-covert runs everytime when user login (/etc/xdg/autostart/gsettings-data-convert.desktop)

Since gconf is deprecated,
could we just modify /usr/sbin/guest-account ,
add an autostart script in the guest $HOME/.config/autostart/
and let gsettings set the correct default value for disable-lock-screen?

And also set X-GNOME-Autostart-Phase=Initialization so the menu will not have the entry.

As Tyson mentioned in comment #28, this is a timing issue that gsettings-data-convert.desktop is executed before gconf value is set for guest session.

One of workaround to use gsettings is to put a prefs.sh in /etc/guest-session which does:

echo "[Desktop Entry]\nType=Application\nName=Disable Lock Screen in Guest Session\nOnlyShowIn=GNOME;Unity;\n\
X-GNOME-Autostart-Phase=Initialization\nTerminal=false\n\
Exec=gsettings set org.gnome.desktop.lockdown disable-lock-screen true\nNoDisplay=true" \
> $HOME/.config/autostart/disable-lock-screen.desktop

chown $USER:$USER $HOME/.config/autostart/*

This will make sure the gsettings value of disable-lock-screen can always be true for guest session.

I think "gconftool-2 --set --type bool /desktop/gnome/lockdown/disable_lock_screen True" in guest-account can be replaced by the script attached in comment #31 or something similar since gconf should be replaced by gsettings.

Thanks everyone for the work there, some comments:
- using gconftool to write the value and relying on the migration script to copy it over to gsettings is just wrong, we should stop doing that
- we didn't change it by then, there was a problem with writting to gsettings directly ... but I can't remember which one...
- comment #4 suggests that gsettings' upstream recommended using a custom dconf database as a reliable way

Did anyone try to modify /usr/sbin/guest-account to just call "dbus-launch gsettings set org.gnome.desktop.screensaver lock-enabled"? That should probably work (if the XDG_RUNTIME_DIR that stores the dconf database exists)

debian/guest-account: disable screen locking in a more reliable way.
Rather than trying to write a key for another user, while setting up the
guest user account, just set up an autostart desktop that will set it
during the login (lp: #951000)

I've uploaded to saucy and raring, could somebody on precise test the change there and see if that fixes the issue? (there is another SRU in the queue so we will need to wait to upload there anyway)

add "dbus-launch gsettings set org.gnome.desktop.lockdown disable-lock-screen true" works to disable lock-screen option in the menu.

> add "dbus-launch gsettings set org.gnome.desktop.lockdown disable-lock-screen true" works to disable lock-screen option in the menu.

that doesn't work, at least not in the guest-session script, since it's not running under the right user

Hello Gary, or anyone else affected,

Accepted lightdm into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.6.0-0ubuntu3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This bug was fixed in the package lightdm - 1.7.3-0ubuntu2

---------------
lightdm (1.7.3-0ubuntu2) saucy; urgency=low

  * debian/guest-account: disable screen locking in a more reliable way.
    Rather than trying to write a key for another user, while setting up the
    guest user account, just set up an autostart desktop that will set it
    during the login (lp: #951000)
 -- Sebastien Bacher <email address hidden> Tue, 25 Jun 2013 22:30:04 +0200

I guess this bug don't help us Kubuntu user as gsettings is Gnome package?

@Sebastien, what do you mean it doesn't work in guest-account script?
I did add it into guest-account script to replace gconf command.
The dbus-launch will create a session bus and set disable-lock-screen properly for guest user.
I am curious why it doesn't work for you?

@Tammy: did you read my previous comment? guest-account is ran by the lightdm user, not the guest session once, the configuration is going to be written at the wrong place ... it's also a less robust way to do that. What's the issue with the fix that has been upload? Did you try it or du you just argue for the sake or arguing?

@Sebastien, thanks for your reply.
I have tried the patch; it works good as expected and I have no issue with it.

The reason I tried "dbus-launch gsettings set org.gnome.desktop.lockdown disable-lock-screen true" was because you commented on our private bug and ask us to try dbus-launch. Therefore, I assumed you still expected my reply.

Your patch works perfectly on the machine I tested, but I still hope to understand the reason why dbus-launch gsettings does not work for you. In the old guest-account, it does the following

  su $USER <<EOF
  gconftool-2 --set --type bool /desktop/gnome/lockdown/disable_lock_screen True
EOF

Since it su to guest user, it is reasonable to me that the gsetting can be set properly for guest user, and that is also what I see when I made tests to use "dbus-launch gsettings". I will be very happy to know what kind of difference causes "dbus-launch gsettings" not function in your side but my side.

> @Sebastien, thanks for your reply.
> I have tried the patch; it works good as expected and I have no issue with it.

great ;-)

> The reason I tried "dbus-launch gsettings set org.gnome.desktop.lockdown disable-lock-screen true" was because you
> commented on our private bug and ask us to try dbus-launch. Therefore, I assumed you still expected my reply.

Oh, sorry about that, my first though was to replace the gconftool call by a gsettings one, but that turned out to be too flacky, which is why I changed for the approch used there

> Since it su to guest user, it is reasonable to me that the gsetting can be set properly for guest user, and that is also what I see when I made tests to use "dbus-launch gsettings". I will be very happy to know what kind of difference causes "dbus-launch gsettings" not function in your side but my side.

Well, it's maybe due to the way I tested/debugged it (running the guest-session add script by hand) because I was getting the warnings robert_ancell mentioned earlier: "unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly.".

In any case going through: su -> dbus activation (dbus-launch) -> starting dconf-service -> write the key is lots of steps and seems not the most robust way, it's also expensive since it's going through user loginn dbus activation, etc.

The bug here also showed that the "run a command through su and rely on infos to be written to the right place" was flacky (the gconftool->migration approch worked half of the time), so I was reluctant building on the same base.

In summary: I think the current approch is safer, just log in an let the session run the command, no dbus activation, no su hackering ... just a normal command running in the user session context ;-)

I hope that makes sense

Yep, that answers my question and I totally agree the final approach is more reliable! Many thanks.

(uploaded for precise as well)

Hello Gary, or anyone else affected,

Accepted lightdm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.2.3-0ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I've verified lightdm 1.6.0-0ubuntu3 on raring and lightdm 1.2.3-0ubuntu2.3 on precise. This SRU looks good.

Test steps:
1. apt-get update
2. apt-get dist-upgrade
3. enable raring-proposed (or precise-proposed)
4. apt-get install lightdm
5. logout
6. login as guest
7. make sure ctrl-alt-L has no function and menu indicator does not have a "Lock screen" entry.
8. logout
9. repeat step 6-8 10 times.

I used similar steps of Hao-Ran Liu's and tested them in original Ubuntu 12.04.2 precise environment. The 'Lock scree' entry will occur once in 10 times. With upgrade lightdm to 1.2.3-0ubuntu2.3, I ran about 30 times but it did not happen anymore.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package lightdm - 1.2.3-0ubuntu2.3

---------------
lightdm (1.2.3-0ubuntu2.3) precise; urgency=low

  * debian/guest-account: disable screen locking in a more reliable way.
    Rather than trying to write a key for another user, while setting up the
    guest user account, just set up an autostart desktop that will set it
    during the login (lp: #951000)
 -- Sebastien Bacher <email address hidden> Mon, 08 Jul 2013 13:47:53 +0200

This bug was fixed in the package lightdm - 1.6.0-0ubuntu3

---------------
lightdm (1.6.0-0ubuntu3) raring; urgency=low

  * debian/guest-account: disable screen locking in a more reliable way.
    Rather than trying to write a key for another user, while setting up the
    guest user account, just set up an autostart desktop that will set it
    during the login (lp: #951000)
 -- Sebastien Bacher <email address hidden> Tue, 25 Jun 2013 22:30:04 +0200

This is Fix Released on Precise \o/

This bug still affects me with Ubuntu 13.04 and lightdm version 1.6.0-0ubuntu3 with KDE as the desktop environment.

Is this fix gnome specific? Is it possible to fix this issue for both desktop environments?

what is KDE to lock the screen? the change there was to set a key that gnome-screensaver is reading...

+1 for KDE. This bug makes guest sessions useless.