I don't entirely understand what you're saying, can you reiterate in more detail?

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.

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.

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.

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.

(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..

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.

Be wary that we don't trip SELinux about this.

(In reply to comment #6)

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

Put my recollections in bug 701393

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.

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.

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.

Review of attachment 245868 [details] [review]:

You might want to point out that this file is only created for new user modes.

(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.

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.

Review of attachment 245870 [details] [review]:

OK.

(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?

(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.

(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.

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

Can we please get this fixed ported down to F19? The bug is a blocker for F19 release. Thanks!