ni...@lysator.liu.se (Niels Möller) skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> On GuixSD we now use ‘pam_env’ to address the issue of initializing >> PATH, and before that we had /etc/profile do the right thing. So this >> is fine. > > And lsh doesn't play well with pam, though... (It will be easier in the > development version, where userauth is its own process). > >> In the test environment, we cannot rely on this, though. > > No chance you can put back an /etc/profile in the build container?
No. I think tests should minimize assumptions about things that are outside of the build tree. Another option would be to have the test environment define a custom HOME and provide an appropriate $HOME/.profile. Thoughts? >> So I think the >> only viable options are the patch I posted, or inheriting PATH as you >> suggest (but that option should be used for testing only IMO.) > > I don't have the code in front of me now, but for HOME, I think the > logic is if the uid of the lshd proces equals the uid of the user > logging in, HOME is inherited. Maybe it would make sense to do the same > for PATH? Seems like complicated semantics that could surprise users. > Otherwise, we'd need some command line option to either enable > inherit, or explicitly specify the value of PATH. That seems more reasonable: in practice, this would only be used for tests, I expect, avoid bad surprises. Ludo’. _______________________________________________ lsh-bugs mailing list lsh-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
