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 679474 - rework the gdm integration
rework the gdm integration
Product: gnome-initial-setup
Classification: Applications
Component: general
Other Linux
: Normal normal
: ---
Assigned To: GNOME Initial Setup maintainer(s)
GNOME Initial Setup maintainer(s)
Depends on:
Reported: 2012-07-05 21:57 UTC by Matthias Clasen
Modified: 2012-11-06 06:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Matthias Clasen 2012-07-05 21:57:40 UTC
There is a number of problems with the current way we are copying the settings into the new users home directory currently:

- It assumes the home directory is there, without logging in as the user. That doesn't work in general for enterprise accounts and automounted nfs home directories

- It copies files using 'pkexec install' which won't work in general, since root won't have the permissions to copy into a home directory (in particular a nfs-mounted one)

- We currently use autologin to switch into the user session at the end, which won't work for enterprise accounts either

To fix all these problems, we've come up with the following approach:

1) Start the initial-setup session as we do currently

2) When we have the user credentials collected (and created a user, in the local case), call into the slave to create a 'germ' of the user sesssion. This will be another worker which starts a little custom program instead of gnome-session.

3) The custom program opens a direct communication channel with gnome-initial-setup by passing an fd through the slave, and they talk p2p dbus over it

4) The copying of the files happens over this communication channel

5) When the initial-setup is done, the custom program execs gnome-session, to get the full user session started.
Comment 1 Stef Walter 2012-07-06 10:42:39 UTC
That sounds like a good plan. A nice middle of the road running the setup as the user and the pitfalls when trying to create/initialize the home directory from outside login.

Off the top of my head, I think even gnome-keyring-daemon would work here. It would be started with the --login option via PAM when starting the 'germ' user session, and then it would be initialized later by gnome-session (via autostart). It doesn't read the keyring or try to unlock it until the later initialization, so there's time to place login.keyring in the right place.
Comment 2 Matthias Clasen 2012-07-06 12:57:57 UTC
ah, excellent
Comment 3 Jasper St. Pierre (not reading bugmail) 2012-07-30 23:57:00 UTC
Change of plans after talking with Lennart today. We can't launch a special germ session, as that would cause device policy to break.

The recommended solution was to dump a bunch of stuff to a place like /run/initial-setup-$username/, and add a session file to check for it at startup.
Comment 4 Ray Strode [halfline] 2012-07-31 14:22:25 UTC
device policy to break?
Comment 5 Jasper St. Pierre (not reading bugmail) 2012-07-31 14:24:43 UTC
Devices are attached to a TTY/PAM pair in pam-systemd. If we start another PAM conversation on the same TTY, devices will belong to the new session.
Comment 6 Ray Strode [halfline] 2012-07-31 14:29:32 UTC
which is what we want since we're about to transition to that session, right?
Comment 7 Ray Strode [halfline] 2012-07-31 14:40:12 UTC
I'd like to point out we do this today going from the greeter session 
to the user's session.
Comment 8 Lennart Poettering 2012-07-31 15:01:53 UTC
Ray, but we don't really have two sessions on the same tty around at the same time, do we? That'd be racy. The whole model is designed so that a seat (and its devices) belongs to one session only (and hence one user only) at a time. Running to sessions on the same seat at the same time creates a few issues as various things would start fighting for device access.

Are you sure that in the current code the PAM session of the human user is created before the PAM session of the gdm user has ended? I'd assume that not.
Comment 9 Lennart Poettering 2012-07-31 15:06:55 UTC
to clarify this: by "two sessions on the same tty around" I actually mean "two sessions on the same seat and tty around".
Comment 10 Ray Strode [halfline] 2012-07-31 15:54:08 UTC
Yup, there's a small overlap.  There has to be since, we can't even know if the login really, truely succeeded until pam_open_session finishes.
Comment 11 Lennart Poettering 2012-08-03 17:40:43 UTC
Hmmm, OK, so I had a closer look at what is currently implemented in logind. We indeed do allow two sessions to be bound to the same seat/VT. In such a case the newer one is the one which owns all the devices, and the older one won't. It's probably sensible to have a logic like this and keep it like this.

Summary: I guess passing the data in question between two running sessions would be kinda OK after all, but I'd still very much prefer to terminate one and then start the other and pass the data in a file -- since it is a bit surprising that we allow two sessions on the same seat/VT, and it might be confusing in logs/audit/yadda yadda.

But anyway, you can close this if you want.
Comment 12 Ray Strode [halfline] 2012-08-03 18:00:21 UTC
well this bug is for the general "initial setup" feature, not that side issue.

There's no way to do what you're suggesting. There necessarily has to be an overlap (unless we stop using pam_systemd).

We could introduce some transition state or something to make it more official.
Comment 13 Matthias Clasen 2012-10-03 13:20:40 UTC
Mostly done now.
Comment 14 Matthias Clasen 2012-10-03 13:50:08 UTC
One thing that is left to do is finding the right place to run the cleanup that removes the gnome-initial-setup, as well as the /var/lib/gdm/run-initial-setup file. We've moved it to some other place, but now it isn't getting called at all.
Comment 15 Matthias Clasen 2012-11-06 06:27:29 UTC
done now