Update PAM policy to allow password-less logins set up via users-admin

I've subscribed ubuntu-security to take a look at that.

the debdiff has a typo in the group naming

Woops! A good start would be to get group names right... Anyways, there was also a tabulation problem, the new patch uses spaces for aligns.

The issue is fixed in karmic now

Sorry Sebastien, but I've checked the file gdm.pam in gdm 2.27.4-0ubuntu6, and it's not applied. The upstream default file includes the required line, but AFAIK it's not used.

Here's the debdiff against GDM 2.27.4 which is now in Karmic. Please review!

Ping...

I'm not sure why the Ubuntu Security Team has been unsubscribed from this bug, but please have a look at that and leave a quick comment. Then the debdiff is ready to be applied... Thanks!

Another try to get this reviewed? Launchpad has not updated the upstream report status, which has been fixed for a long time actually. The gnome-system-tools also have this in Karmic for more than a month. What's the point in adding new features upstream if distributors don't follow? We're going to show a greyed out check box if nothing is done, really not user-friendly...

I didn't know this was implemented upstream already (didn't check before, actually).

This is something many people ask for when I install Ubuntu for them, e.g. to allow young kids to use a computer without needing to enter a password, while still preventing them from destroying their mom & dad's files... :-)

Would be nice if we could get this in karmic before the release.

@Milan: if you fold open the "affects gdm" line, Launchpad says that that bug doesn't exist... weird?

Jan: I think Launchpad remote bug watches have had some trouble with the new GNOME Bugzilla, but it seems to have been solved in other bugs yesterday.

My use case is different. My parents are near retirement and just want a super-easy-to-use computer; that means security via physical access only. Accounts are merely a preference filing system to them.

Password-less accounts in the admin group are a questionable thing; but if that's what the system-administrator sets up that is what they have decided to use or their clients have demanded. In that case the accounts should still be able to authenticate.

The use case of children, guests, and other password-less accounts should involve removal of the admin and likely some other groups or accounts that never had those groups.

Further, it would be -extremely- nice to have an account editing tool that could create new accounts and visually diff existing accounts against template users (such as guest, system-administrator, etc).

MichaelEvans: I did not post you the link to this bug so that you say me "it's not what I'm asking for". Please don't use reports about a precise issue as a general-purpose forum.

And user profiles already exist in users-admin, currently we have Admin, Desktop User and Unprivileged. So just create a Desktop User account for you parents, and an Admin one for you, using that one to authenticate when performing admin tasks. But we should definitely not discuss this here.

Sorry, I was trying to clarify potential use cases, both for passwords with and passwords without sys-admin capabilities. Editing accounts is probably some other bug... all the usability issues that I see as related actually collections of different bugs. Each bug a small piece of grit fouling the smooth accomplishment of a task. I'll try to break away from the task and instead focus on the pathology of each individual grit.

Also, I just noticed when going to file the other wishlist bug... Why was my bug linked to GDM as a duplicate? I specifically chose the proper package and hadn't looked; this isn't related to mine at all!

MichaelEvans: Your bug was about a use case that we don't consider as valid. There are other means of achieving the same thing (password-less account), which we consider as better for everyone. So I could mark your bug as Invalid, or as a duplicate of this one, which should also allow you to do what you want. If you don't like that, I can remove that, but that does not really matter.

Given that this was supposed to be fixed before Karmic release, the fix is known, and we've now shipped a greyed-out checkbox to users, is this likely to get fixed in Karmic, or should I tell my dad to expect it in Lucid only?

The pam_unix module in Ubuntu supports granting access to passwordless accounts by way of the 'nullok_secure' option, which says: accounts with a null password field are allowed access, as long as the connection is on a "secure" tty (defined by /etc/securetty). This is already in effect by default for all services, including gdm; I don't think it's appropriate to have two separate mechanisms for configuring passwordless logins on the system. Adding a special group to the system is, in particular, a design that's rather unnecessarily complex.

(The nullok_secure support in pam_unix is still in need of upstreaming to Linux-PAM, so it's understandable that gdm upstream isn't using that instead; still, I don't think we want this patch.)

The rationale behind this feature vs. the standard nullok_secure way is that *you actually have a password*. This means users can be admins, type their password to use sudo, PolicyKit or lock their screen, but they are not asked to type it on login. They can additionally connect over local SSH for example.

There are many use cases for this - if you consider how people are used to configure their Windows home computers for example: as long as you're not the only user on the box (-> GDM autoconnect), you are forced to type your password. So if you want to avoid that without losing all security, and that you want to be an admin (quite common), you need this feature.

users-admin has never allowed people to use an empty password because of security considerations. I've already closed several feature requests like that. Are you suggesting we should make it easy to use empty passwords ("Use no password' " button)? I'd find it quite bad, but OTOH we need an easy way for people to skip this step if they don't want to type a password.

The current situation can be counter-productive: friends of mine are using silly passwords such as "xxxx" because they don't care. If we weren't forcing them to type passwords on login, I would happily force users to choose a strong password in users-admin, which would improve security.

So all in all, I see more use cases for this method than for the traditional nullok_secure option. Dropping the latter wouldn't hurt IMHO if we can provide a better approach.

Using Ubuntu 9.10 I just added manually the new line from the patch to /etc/pam.d/gdm:

auth sufficient pam_succeed_if.so user ingroup nopasswdlogin

And afterwards I created the usergroup:

sudo addgroup --system nopasswdlogin

Then the option in "Users and groups" wasn't greyed out anymore and everything worked as expected!

Thanks a lot for the patch, I hope it will make it into 10.4!

There is a problem with passwordless logins and the default configuration of karmic: you can't change the language (and whatever you'd like to configure in GDM), because the buttons are hidden until you choose a user...

Don't know if it's possible to display the buttons also before selecting a user.

Pushed to gdm packaging branch. Thanks Milan, and sorry that this took so long! At least it comes in time for the LTS :)

Thanks! Right, that took quite a long time - I first started to think about that about two years ago... But LTS is what matters.

lumbricus: could you open a report about the configuration bug you describe, and post the link here? I'm not sure that will be an easy one to fix, but better keep track of it.

Ok, I opend a new bug for the problem with hidden options before selecting a user:
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/508552

Fix released before 10.04 at long time ago.