Bug 1389929

The original BZ from RHEL6 has been closed, but it seems appropriate to consider fixing this in RHEL7, where it (according to comments) should be easier fix this in systemd...

+++ This bug was initially created as a clone of Bug #1227935 +++

When an user with an expired password, it is desirable to
receive a localized message, instead of:

You are required to change your password immediately (root enforced)

I tried all combinations I could think of, of using pam_env,
changing order of entries in /etc/pam.d files, settings
in /etc/environment and /etc/security/pam_env.conf, but
reading pam code, it does not really appear to setlocale,
and/or parse locale information. So, it will only print
localized messages if doing something like

$ su - user-that-needs-password-reset

and already having the locale set in the environment.

--- Additional comment from Paulo Andrade on 2015-06-04 03:38:39 CEST ---

As a side note, the best I could find, kind of related, is
https://www.novell.com/documentation/idm40drivers/bi_impl_nx/data/b3yj5z9.html
look at the LC_ALL setting.
So, it should be required some kind of configuration to
tell Linux-PAM to use an specific locale.
A quick grep on /etc/ shows it would likely be parsing
/etc/locale.conf on rhel7 or /etc/sysconfig/i18n on rhel6,
checking for LANG, and setting the locale, so that any text
output would be translated.

--- Additional comment from Tomas Mraz on 2015-06-04 13:00:26 CEST ---

Do you ask for systemwide locale setting or per-user?

--- Additional comment from Paulo Andrade on 2015-06-05 14:47:59 CEST ---

A system wide one.
Special handling of a LANG entry on /etc/security/pam_env.conf
could be the best option.
I suggested earlier
* /etc/locale.conf on rhel7 
or
* /etc/sysconfig/i18n on rhel6
because those are single line files with LANG setting.

A different approach could be what Debian does, but that still
does not change messages from pam itself, unless Debian has
patches for this scenario (I did not check), e.g. Debian pam
configs have something like:

session       required   pam_env.so readenv=1 envfile=/etc/default/locale

--- Additional comment from Tomas Mraz on 2015-06-08 10:11:46 CEST ---

If you need just system wide setting then it should be handled by the login utility which calls the PAM library.

I propose changing the component to util-linux.

--- Additional comment from Karel Zak on 2015-08-03 14:13:20 CEST ---

login(1) does not parse any file to set locale, it just calls setlocale(LC_ALL, ""), all the system wide setting should be applied by initscripts/initd before login(1) is executed.

The config file is /etc/sysconfig/i18n  (or localectl and /etc/locale.conf on systemd based distros).

Note that login(1) *after* successful authentication and session initialization resets environment and applies stuff from PAM (pam_getenvlis()) ... then it  executes shell where in the profile files is expected per-user locale setting. I don't think that $LANG (or so) in pam_env.conf makes any sense.

Paulo, is it what are you asking for?

--- Additional comment from Paulo Andrade on 2015-08-03 17:00:39 CEST ---

What the customer wants is to have this string translated:

"""
You are required to change your password immediately (root enforced)
"""

when logging in and needing to change the password.
I had initially reported it to pam because the string
comes from pam.
https://git.fedorahosted.org/cgit/linux-pam.git/tree/modules/pam_unix/pam_unix_acct.c#n252

--- Additional comment from Karel Zak on 2015-08-20 13:02:28 CEST ---

The question is if we really have a simple solution for this issue. 

See bug #663900 from time we have upgraded from initscripts to systemd. The problem is that we cannot blindly apply arbitrary locale setting (from /etc/sysconfig/i18n) in time we execute getty+login, because Linux console can not display all required glyphs. We use /etc/profile.d/lang.sh *after* login to filter out a problematic setting according to terminal setting.

I have doubts it's possible to do so complex thing in old initd before it spawns getty+login. I don't see a way how to fix it in login(1).

Reassign to init scripts.

Note that with systemd it seems much better and login(1) messages are translated.