Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#16991 - [slim] causes pam_env to read garbage into environment
Attached to Project:
Arch Linux
Opened by Jay Tanzman (jt512) - Tuesday, 03 November 2009, 17:36 GMT
Last edited by Andrea Scarpino (BaSh) - Saturday, 07 November 2009, 01:44 GMT
Opened by Jay Tanzman (jt512) - Tuesday, 03 November 2009, 17:36 GMT
Last edited by Andrea Scarpino (BaSh) - Saturday, 07 November 2009, 01:44 GMT
|
DetailsDescription:
/etc/pam.d/slim contains the following line: session required pam_env.so readenv=1 envfile=/etc/profile.d/local e.sh However, the contents of /etc/profile.d/locale.sh, written by /etc/rc.sysinit, are as follows: export LANG=en_US.utf8 if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\e%%G"; fi if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\e(K"; fi And pam_env attempts to parse these lines as if they were in KEY=VAL format, resulting in garbage being read into the environment. One consequence of this is that it breaks the "at" daemon for users who have logged in using SLiM. Additional info: * package version(s) slim-1.3.1-4 * See attached output of `env` and `at -c` Steps to reproduce: 1. Verify that /etc/profile.d/locale.sh contains lines similar to those above. If not, then see /etc/rc.sysinit. 2. Log in, as ordinary user, using SLiM 3. $ env (Output should contain garbage from /etc/profile.d/locale.sh) 4. $ at now + 1 min at> echo Hello World at> Ctl-D 5. $ at -c <job #> (Output should contain garbage, as above) 6. After 1 min, check email. Should receive mail containing error message from 'at' job: "sh: line 58: syntax error: unexpected end of file." Workaround: Set readenv=0 in /etc/pam.d/slim |
This task depends upon
Closed by Andrea Scarpino (BaSh)
Saturday, 07 November 2009, 01:44 GMT
Reason for closing: Fixed
Additional comments about closing: slim 1.3.1-5
Saturday, 07 November 2009, 01:44 GMT
Reason for closing: Fixed
Additional comments about closing: slim 1.3.1-5
env.txt
at version 3.1.10.2-1
if I don't wrong it is needed to parse environment file
FS#16282.Before that line was added, slim did not pass LANG properly, thus creating problems for applications that needed it set.
The problem is that along with parsing the first line, "LANG = ...", it also parses the next lines.
A workaround would be creating a file containing only the necessary assignments for setting LANG properly within slim.
Either that or modifying the actual source code.
@Alex: On my computer there doesn't seem to be a problem with how SLIM handles the LANG variable. I don't need to have SLiM read $LANG into the environment. It is already there. /etc/profile.d/locale.sh is evidently sourced when bash starts.
Simply reverting the fix will not do. Since sourcing the /etc/profile.d/locale.sh file is problematic, and as far as I know, there is no other file we can source (Debian has /etc/default/locale, but I found no such file in Arch), maybe something can be done in /etc/init.d/slim.
In Debian they source and export the values of the /etc/default/locale file, which contains entries in the form of LANG="en_US.utf" using a script under /etc/X11/Xsession.d/.
Nov 6 16:05:33 rock slim: pam_env(slim:session): non-alphanumeric key 'if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\e%%G"; fi' in /etc/profile.d/locale.sh', ignoring
Nov 6 16:05:33 rock slim: pam_env(slim:session): non-alphanumeric key 'if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\e(K"; fi' in /etc/profile.d/locale.sh', ignoring
Why not test slim without the pam_env line at all. It's working on my computer. Maybe the bug that the line was put in to fix has been fixed upstream.
@Alex
if this cause issues for you, re-open
FS#16282