After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701100 - gnome-initial-setup configured settings get applied to all accounts created before first reboot instead of only the account created by gnome-initial-setup
gnome-initial-setup configured settings get applied to all accounts created b...
Status: RESOLVED FIXED
Product: gnome-initial-setup
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Initial Setup maintainer(s)
GNOME Initial Setup maintainer(s)
Depends on: 701472
Blocks: 701473
 
 
Reported: 2013-05-27 20:36 UTC by Rui Matos
Modified: 2013-06-12 17:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
summary: Create a file with the user ID we added (1.90 KB, patch)
2013-06-02 17:55 UTC, Rui Matos
committed Details | Review
copy-worker: Exit if the skeleton directory isn't ours (1.83 KB, patch)
2013-06-02 17:55 UTC, Rui Matos
committed Details | Review
copy-worker: Don't attempt to delete the skeleton directory (1.20 KB, patch)
2013-06-02 17:55 UTC, Rui Matos
committed Details | Review

Description Rui Matos 2013-05-27 20:36:35 UTC
gdm should remove or set aside the gnome-initial-setup home dir. Otherwise, if one creates further user accounts and tries to log in to them before rebooting the system, gnome-initial-setup-copy-worker will do its thing, causing gnome-initial-setup itself to not run and going directly to run-welcome-tour.
Comment 1 Ray Strode [halfline] 2013-05-28 13:32:24 UTC
I don't entirely understand what you're saying, can you reiterate in more detail?
Comment 2 Rui Matos 2013-05-28 13:56:59 UTC
Let's say I just installed F19 without user accounts.

1) GDM starts up in the special gnome-initial-setup mode
2) I create a user there and log in to it
3) inside this session I now create more user accounts
4) I log out and log in to one of these newer accounts
5) instead of seeing the "regular" gnome-initial-setup for this new user account, the welcome tour starts immediately and this accounts settings are those of the first user created.

Although I'm not 100% sure (I just looked at the code for a bit) I think that this is because the special gnome-initial-setup home directory (/run/gnome-initial-setup) created by GDM remains around (until reboot).

i.e. this check https://git.gnome.org/browse/gnome-initial-setup/tree/gnome-initial-setup/gnome-initial-setup-copy-worker.c#n60 fails and we go on and copy the settings into all new accounts. Until reboot.
Comment 3 Ray Strode [halfline] 2013-05-28 14:09:51 UTC
Okay, i think I see what you're saying.  GDM doesn't create any of the initial-setup stuff though, it merely runs gnome-initial-setup which does all the heavy lifting itself.

Jasper, Matthias, and I had a discussion last week about gnome-initial-setup, and i think the plan was to change how it gets run, so that it gets run for secondary users anyway, which should fix this bug at the same time.
Comment 4 Matthias Clasen 2013-05-30 14:20:22 UTC
I don't think any of that is going to happen for f19.
So we should make sure we clean up /run/gnome-initial-setup when the copying is done, or at least make sure we don't try to copy anything for a secondary user.
Comment 5 Adam Williamson 2013-05-30 19:22:04 UTC
Just a note this has been accepted as a blocker bug downstream as it could expose the admin user's personal accounts / settings to other users without the admin user being aware of it:

https://bugzilla.redhat.com/show_bug.cgi?id=968951

so we need to fix it up at least somehow for f19 final.
Comment 6 Michael Wood 2013-05-31 15:18:15 UTC
(In reply to comment #3)
> Okay, i think I see what you're saying.  GDM doesn't create any of the
> initial-setup stuff though, it merely runs gnome-initial-setup which does all
> the heavy lifting itself.
> 
> Jasper, Matthias, and I had a discussion last week about gnome-initial-setup,
> and i think the plan was to change how it gets run, so that it gets run for
> secondary users anyway, which should fix this bug at the same time.

Would be good to have insight into the discussions.

In the gnome-initial-setup-copy-worker we use g_file_delete which probably won't do anything because the directory is not empty.

Would the right thing be to g_file_enumerate_children , I don't see a nice gio function to recursive delete..
Comment 7 Rui Matos 2013-05-31 15:24:45 UTC
Michael, I'm working on this, currently testing patches.

Basically the approach I'm taking is to have gdm chown() the /run/gnome-initial-setup directory to the UID of the user just created and tighten the unix permissions on it so that only that UID will be able to access it.
Comment 8 Jasper St. Pierre (not reading bugmail) 2013-05-31 16:50:21 UTC
Be wary that we don't trip SELinux about this.
Comment 9 Matthias Clasen 2013-05-31 21:13:33 UTC
(In reply to comment #6)

> 
> Would be good to have insight into the discussions.
>

Put my recollections in bug 701393
Comment 10 Rui Matos 2013-06-02 17:55:34 UTC
Created attachment 245868 [details] [review]
summary: Create a file with the user ID we added

This will allow third parties to easily discover which user ID was
added to the system.
Comment 11 Rui Matos 2013-06-02 17:55:40 UTC
Created attachment 245869 [details] [review]
copy-worker: Exit if the skeleton directory isn't ours

If the skeleton directory isn't ours we shouldn't be copying anything
from it. Depending on its permissions we might even be unable to copy
and then we'd still go on and added our gnome-initial-setup-done flag
file erroneously.
Comment 12 Rui Matos 2013-06-02 17:55:48 UTC
Created attachment 245870 [details] [review]
copy-worker: Don't attempt to delete the skeleton directory

This would have to be a recursive deletion to work but we don't even
need to do that since the permissions on it don't allow anyone else to
snoop and it will go away in the next reboot.
Comment 13 Jasper St. Pierre (not reading bugmail) 2013-06-04 16:50:26 UTC
Review of attachment 245868 [details] [review]:

You might want to point out that this file is only created for new user modes.
Comment 14 Rui Matos 2013-06-04 17:27:44 UTC
(In reply to comment #13)
> You might want to point out that this file is only created for new user modes.

Ok, I added this comment before calling add_uid_file()

  /* We are in NEW_USER mode and we want to make it possible for third
   * parties to find out which user ID we created.
   */

What about the other patches? At least the 2nd one is necessary otherwise g-i-s won't run when logging into secondary accounts created after the first and before rebooting.
Comment 15 Jasper St. Pierre (not reading bugmail) 2013-06-04 17:42:28 UTC
Review of attachment 245869 [details] [review]:

I wonder if it makes sense to have skeleton dirs named with the UID, instead of this. This runs during early boot, so it should be relatively quick to exit if it needs to do nothing.
Comment 16 Jasper St. Pierre (not reading bugmail) 2013-06-04 17:47:33 UTC
Review of attachment 245870 [details] [review]:

OK.
Comment 17 Rui Matos 2013-06-04 18:09:11 UTC
(In reply to comment #15)
> Review of attachment 245869 [details] [review]:
> 
> I wonder if it makes sense to have skeleton dirs named with the UID, instead of
> this. This runs during early boot, so it should be relatively quick to exit if
> it needs to do nothing.

Sorry, I don't undertand you here, can you elaborate a bit more on what you're thinking?
Comment 18 Jasper St. Pierre (not reading bugmail) 2013-06-04 22:28:44 UTC
(In reply to comment #17)
> Sorry, I don't undertand you here, can you elaborate a bit more on what you're
> thinking?

Whoops, I thought we still created the skeleton dir explicitly in /run/, rather than using the gnome-initial-setup's home dir from pwent.

Additionally, what happens if, after we create the initial user account, the user makes a new account from the panel and then immediately logs in with that new account. GIS's homedir will be there, but inaccessible. I'm quite sure something will fail in a marvelous way.
Comment 19 Rui Matos 2013-06-05 08:10:53 UTC
(In reply to comment #18)
> Additionally, what happens if, after we create the initial user account, the
> user makes a new account from the panel and then immediately logs in with that
> new account. GIS's homedir will be there, but inaccessible. I'm quite sure
> something will fail in a marvelous way.

The second patch here covers that case. copy-worker will notice that /run/gnome-initial-setup isn't owned by the current user and exit, which means that g-i-s then runs regularly inside the new user's session.
Comment 20 Rui Matos 2013-06-06 08:12:38 UTC
As discussed on IRC this is not ideal but fixes the issue for now with
the current architecture.

Attachment 245868 [details] pushed as 04e0ad1 - summary: Create a file with the user ID we added
Attachment 245869 [details] pushed as 8706a28 - copy-worker: Exit if the skeleton directory isn't ours
Attachment 245870 [details] pushed as 1f9c2bd - copy-worker: Don't attempt to delete the skeleton directory
Comment 21 Adam Williamson 2013-06-12 17:49:06 UTC
Can we please get this fixed ported down to F19? The bug is a blocker for F19 release. Thanks!