Arch Linux

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!
Tasklist

FS#41232 - [filesystem] /etc/profile.d/locale.sh mangles locale variables sent from ssh

Attached to Project: Arch Linux
Opened by Glen Huang (hgl) - Thursday, 17 July 2014, 06:59 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 27 July 2014, 14:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

/etc/profile.d/locale.sh unsets locale variables which can prevents locale variables sent from ssh from being applied.

Content of my /etc/profile.d/locale.sh
http://pastebin.com/z0tepG6e
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 27 July 2014, 14:44 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Proposed solution will create bugs of its own, and I don't think this particular use case is common enough to warrant a generic solution (if one exists).
Comment by Dave Reisner (falconindy) - Thursday, 17 July 2014, 11:57 GMT
What's the use case for sending these vars through ssh (which requires client/server cooperation) rather than just leaving these settings to your remote shell .profile?
Comment by Glen Huang (hgl) - Sunday, 20 July 2014, 10:00 GMT
I might be wrong, but I thought leaving these vars untouched could allow different users to use different locales when they ssh into the machine? Doesn't leave these settings to .profile forces everyone to use the same locale?
Comment by Dave Reisner (falconindy) - Sunday, 20 July 2014, 14:27 GMT
Ssh requires that you set "PermitUserEnvironment" or "AcceptEnv" on the server and use "SendEnv" on the local machine in order to pass environment variables.

> Doesn't leave these settings to .profile forces everyone to use the same locale?
By definition, .profile is per user, and runs after the system-wide /etc/profile.
Comment by Glen Huang (hgl) - Monday, 21 July 2014, 01:52 GMT
> Ssh requires that you set "PermitUserEnvironment" or "AcceptEnv" on the server and use "SendEnv" on the local machine in order to pass environment variables.
I have these options enabled in my sshd and ssh client, that's how I found out env vars are not applied in my ssh session.

> By definition, .profile is per user, and runs after the system-wide /etc/profile.
Oh, you mean per-user .profile? It could work, but it has the following issues:

1. It could prevent users sharing a single ssh account to use different locales.

2. Users are required to explicitly duplicate locale vars, which are already passed to the current session if they have specified the vars in their local shells, in .profile

I think by not unsetting, but only provide default values for locale vars could fix all these issues.
Comment by Dave Reisner (falconindy) - Sunday, 27 July 2014, 14:43 GMT
> 1. It could prevent users sharing a single ssh account to use different locales.
Shared interactive accounts aren't something I have any interest in supporting. It's bad form, plain and simple.

> Users are required to explicitly duplicate locale vars, which are already passed to the current session if they have specified the vars in their local shells, in .profile
Different host, different profile. There's a lot more than just locale that gets "duplicated". What about shell aliases/functions and other initialization?

> I think by not unsetting, but only provide default values for locale vars could fix all these issues.
It also means that your system-wide locale settings will leak into user sessions, creating new bugs.

I think you'll need to find your own solution for your use case.

Loading...