GNOME Bugzilla – Bug 354567
Enable domain logons
Last modified: 2007-02-09 06:40:30 UTC
I've a patch that enables domain logons through GDM. If enabled in gdm.conf (default off), and the theme supports it, it shows a combobox entry where you can select from a list of detected domains (it calls out to wbinfo to get this information) or enter a domain name manually. Behind the scenes, the domain will be prepended to the user name, e.g. user 'hpj' on domain 'mydomain' becomes 'mydomain\hpj'. The rest is up to the PAM modules. This has been tested and should work in an Active Directory environment. The original patch was against an older version of GDM, and this one is slightly redone to account for recent changes. It's against CVS HEAD.
Created attachment 72293 [details] [review] Initial patch.
So Brian wants to have some sort of plugin system developed to handle extending the UI to support module specific things. I'm planning on working on that at some point in the future, although I'm not exactly sure when.
Yes, I guess I'm not sure that the right approach here is to do this by hacking the GDM GUI, although that probably works well for your immediate need. Really, GDM should blindly interact with PAM and PAM should manage collecting such needed information. For example, wouldn't it make more sense for it to work something like this: 1) User enters username 2) PAM receives username, PAM pops up a dialog box (perhaps using zenity) asking for domain selection. The PAM module calls wbinfo to fill the dialog. 3) User enters password Or you could popup the dialog after password, or before username if you wanted to pop-up the dialog in the pam_authenticate step - though this would make GDM hang until the dialog finished. Just saying there's a few ways you could image it working entirely in PAM. This seems a better approach to me than hacking up GDM. Note that there are lots of different users who are wanting GDM to work better with various special login mechanisms (smart cards, etc.) and the point of using PAM is that it shouldn't be necessary to hack up the display manager for each special case. As Ray says, if we do want to enhance GDM to support special GUI's for specific PAM modules, this could be acceptable. However, I'd prefer if this could be implemented in an extensible way. We shouldn't have to hack up GDM for each special case. Perhaps by loading GDM with a GTK_MODULE and then having some sort of configuration to map a PAM message to the GTK_MODULE. This would be better, I think, than hacking up the GDM configuration files with PAM specific stuff and hardcoding special GUI code into GDM. This really should be in a separate GTK_MODULE, I'd think, if not implemented directly in PAM. Ray and I had this discussion before since he wants to add some special smartcard related GUI's, and I think we agreed that this is a better approach.
The PAM module in question must work for both graphical and text logins, so popping up a graphical dialog from that will likely cause trouble (and seems like a gross hack at best). In principle, I agree with you that scenarios like this should be handled in separate modules, but I'm not sure PAM's programming interface/specification is good enough to do this reliably (how would you map PAM messages to modules?).
So I guess if I were writing this patch, I'd punt most of it to the pam module, and just change gdm to be able to support a multiple-choice pam prompt. Note I'm not saying the pam module would ever display dialogs or anything (which I think is a bad idea), but instead it would keep all the authentication specific logic just ask gdm to blindly present whatever UI the module needs. In fact, looking in /usr/include/security/_pam_types.h on my machine, I see there is already a Linux-PAM-specifc prompt type defined called PAM_RADIO_TYPE that seems like it may have been designed for this purpose. If that type is sufficient then you just need to make GDM understand it. If it isn't sufficient, then wouldn't it still be better to fix Linux-PAM to provide something thatdoes work for you, than hack around things in gdm?
If PAM can be made to do what we need, I think you're right. So is the patch officially rejected so we can close the bug?
Nah, i'm just giving my two cents. Brian is the gdm maintainer.
Note that GDM supports "custom lists" where you can specify additional combo boxes or listviews showing a list of choices. Refer to section 8.2.11 here: http://www.gnome.org/projects/gdm/docs/2.16/thememanual.html Why don't you just use this in your theme and then in your PAM module refer to the <var>/gdm/:0.GreeterInfo file to find out what the value was set to? This seems like it would be a bit cleaner than hacking the GDM theme since GDM already supports this kind of mechanism. Perhaps you want to add a feature that forces the user to enter a value in the userlist before the user is allowed to enter a username/password. An enhancement like this would be generic and fairly easy to code. Probably just add a tag element to specify that the username/password entry field will be insensitive until the user picks a value in the custom list? You might also want to enhance the custom lists so that rather than having to hardcode the possible values in the theme, it gets the values by running a script. I think enhancing the existing custom list feature is probably a better and more generic way to support the features you want rather than hardcoding something specific for domains. From a long-term perspective, adding to PAM the ability to support combo lists would be a good idea and avoid the need to use custom lists, but adding such an enhancement to PAM would probably take some time. What do you think?
Ubuntu bug about that: https://launchpad.net/products/gdm/+bug/73440
I think Custom Lists is the right approach to get the feature you want without needing to hack the GUI more directly. So closing this bug report.