19:28 < gusi> halfline: the exact error I get is:
19:28 < gusi> gdm-launch-environment][2550]: in openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 12
19:29 < halfline> gusi: okay so what's going on is..
19:29 < halfline> the login screen is a session like any other
19:30 < halfline> but instead of belonging to a particular real user
19:30 < halfline> it belongs to the "gdm" user
19:30 < halfline> which is a system account
19:30 < halfline> gdm-launch-environment is the pam service used for setting up this session
19:30 < halfline> in the same way the gdm-password pam service is used for setting up a user session
19:30 < halfline> the gdm user doesn't have a password
19:30 < halfline> the pam stack is supposed to be as minimal as possible, basically just enough to do logind registration
19:31 < halfline> the error code you're getting suggests that the pam stack set up for the gdm-launch-environment service thinks that the gdm user has a
                  password
19:31 < halfline> and that that password is expired
19:31 < halfline> and needs to be updated to a new password
19:31 < halfline> of course the gdm user has no way of picking a password
19:32 < halfline> it just expects the pam conversation to silently succeed
19:32 < halfline> because it's not silently succeeding, that suggests the file /etc/pam.d/gdm-launch-environment is misconfigured
19:33 < halfline> or perhaps the gdm user is misdeclared in the /etc/shadow file
19:34 < halfline> gusi: what is the output of sudo grep gdm: /etc/shadow ?
19:35 < halfline> it should be something like gdm:!!:12345::::::
19:35 < halfline> if it's something like gdm::0:0:99999:7::: that's wrong
19:36 < gusi> halfline: let me interrupt you
19:36 < halfline> i'm actually done :-)
19:36 < gusi> :)
19:36 < gusi> mind that it used to work a month ago
19:36 < gusi> and that
19:37 < gusi> we're running FreeBSD
19:37 < halfline> okay so it might be /etc/pam.conf on freebsd? not sure
19:37 < halfline> the point's are still valid though
19:37 < gusi> I've been told that the problem comes from gdm-launch-environment not setting PAM_TTY nor PAM_RHOST
19:37 < gusi> halfline: we have that pam.conf and the gdm-*.pam files in place
19:38 < gusi> but it would appear that a recent commit in our openpam stack broke gdm
19:39 < gusi> the commit fixed a problem were PAM_TTY and PAM_RHOST were not set in pam_login_access
19:39 < gusi> apparently this break gdm-launch-environment
19:40 < halfline> do you have a file /usr/include/security/_pam_types.h ?
19:40 < gusi> /usr/include/security/pam_types.h is in place
19:40 < halfline> can you pastebin it for me?
19:42 < gusi> sure
19:42 < gusi> http://pastebin.com/uAgzB0Ew
19:43 < halfline> ah it's actually pam_constants.h in openpam i guess
19:43 < halfline> https://github.com/aosm/OpenPAM/blob/master/openpam/include/security/pam_constants.h
19:43 < halfline> so 12 is IPAM_AUTHINFO_UNAVAIL
19:43 < gusi> yes
19:44 < halfline> on linux 12 is PAM_NEW_AUTHTOK_REQD
19:44 < halfline> which is why i went down the line of discussion i did before
19:44 < halfline> okay let me look at the code, one moment
19:44 < halfline> i'm pretty sure we do set PAM_TTY
19:44 < halfline> setting PAM_RHOST would be really weird though
19:44 < halfline> it's not a remote connection
19:44 < gusi> I greped and it was at session-worker
19:45 < halfline> right, the code is all in gdm-session-worker.c
19:45 < halfline> so the issue, I guess, is we set PAM_TTY too late
19:46 < halfline> we set it before pam_open_session
19:46 < halfline> but freebsd needs it set before the account stack runs
19:46 < halfline> which is pam_acct_mgmt
19:47 < halfline> that change happened here: https://git.gnome.org/browse/gdm/commit/?id=4cc94727be662fa819f19a4c6d70610380243caf
19:48 < halfline> i assume the person you talked to was saying PAM_RHOST OR PAM_TTY should be set
19:48 < halfline> not both
19:49 < halfline> RHOST if it's a remote connection, and TTY if it's local
19:50 < halfline> so is pam_login_access like pam_loginuid ?
19:50 < halfline> if so it probably shouldn't be run for gdm sessions
19:51 < halfline> since they aren't associated with a human
19:51 < halfline> oh i guess not
19:51 < halfline> http://www.freebsd.org/cgi/man.cgi?query=pam_login_access&sektion=8
19:52 < gusi> yes
19:52 < halfline> can you pastebin your /etc/login.access file?
19:54 < gusi> halfline: it is plain useless in a stock installation, everything is commented out
19:54 < gusi> http://pastebin.com/1Y0yubLT
19:55 < gusi> halfline: I do understand to PAM_TTY or PAM_RHOST should be set (or like a xor)
19:56 < halfline> though, i think it's a bug in the pam module that it requires them to be set for users that aren't confined by the login.access file
19:57 < halfline> if the login.access file says "USER IS ALLOWED TO LOGIN NO MATTER THE TTY OR RHOST" then checking for a TTY or RHOST from the pam module is
                  pretty anti-social
19:58 < halfline> now the question is, i can i fix GDM to work within the wanted constraints given
                  https://git.gnome.org/browse/gdm/commit/?id=4cc94727be662fa819f19a4c6d70610380243caf
19:58 < halfline> s/i can i/can i/
19:58 < gusi> halfline: makes sense, but perhaps we may be missing something
19:58 < gusi> I'm trying to poke our pam maintainer, but he seems unresponsible
20:03 < halfline> it's sort of tricky to fix in GDM
20:03 < halfline> since in some cases we don't know what VT the session is going to be running on until pam_open_session time
20:04 < halfline> so we wouldn't know what PAM_TTY value to use
20:04 < halfline> we could lie
20:04 < halfline> i guess for gdm-launch-environment we know ahead of time
20:05 < halfline> but that won't fix user logins
20:05 < halfline> that'll just get you to a login screen
20:07 < gusi> hmmmm
20:08 < gusi> wouldn't normal users use the system pam stack to login?
20:08 < gusi> hmmmm
20:08 < gusi> do they need the PAM_TTY set?
20:16 < halfline> gusi: normal users do use the system pam stack to login
20:17 < halfline> but the problem is...what tty is their session going to run on?
20:17 < halfline> we don't (necessarily) know until pam_open_session completes
20:17 < halfline> which happens after pam_acct_mgmt is called
20:17 < halfline> if the session runs on the same VT as the login screen then we know
20:17 < halfline> but that's not guaranteed
20:18 < halfline> but the pam module is also a little bit silly
20:18 < halfline> why you would only let tino log in on vt2 and  rebecca log in on vt 3 and vt 5 ?
20:21 < halfline> i guess we could call PAM_TTY early on freebsd only and presume that the login screen and user session will run on the same VT in freebsd
                  always
20:21 < halfline> though before committing that i'd be interested in what the pam maintainers take is
20:26 < gusi> halfline: I'm poking him to pass him this conversation
20:27 < gusi> halfline: thanks a lot your help