GNOME Bugzilla – Bug 679474
rework the gdm integration
Last modified: 2012-11-06 06:27:29 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.
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.
ah, excellent
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.
device policy to break?
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.
which is what we want since we're about to transition to that session, right?
I'd like to point out we do this today going from the greeter session to the user's session.
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.
to clarify this: by "two sessions on the same tty around" I actually mean "two sessions on the same seat and tty around".
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.
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.
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.
Mostly done now.
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.
done now