nisse@lysator.liu.se (Niels Möller) skribis:
ludo@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’.