ludo@gnu.org (Ludovic Courtès) writes:
(This is due to the Guix setup where by default nothing would be found in $PATH; patch attached.
That's a pretty non-standard environment...
Processes spawned for a user by lshd get a pretty trimmed down initial environment, with PATH set to /bin:/usr/bin or something close. If standard unix tools aren't found there, then I think you'd need to either
* have the shell startup files setup a working path (ssh "shell" is implemented by spawning a login shell, and "exec" by starting a shell with -c command-line-string).
* Or some option to lshd to let child processes inherit PATH or set it to a specific value. Not sure if it's appropriate to use that when running the tests, though. There's a related hack to inherit HOME in some circumstances.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) skribis:
ludo@gnu.org (Ludovic Courtès) writes:
(This is due to the Guix setup where by default nothing would be found in $PATH; patch attached.
That's a pretty non-standard environment...
Processes spawned for a user by lshd get a pretty trimmed down initial environment, with PATH set to /bin:/usr/bin or something close. If standard unix tools aren't found there, then I think you'd need to either
have the shell startup files setup a working path (ssh "shell" is implemented by spawning a login shell, and "exec" by starting a shell with -c command-line-string).
Or some option to lshd to let child processes inherit PATH or set it to a specific value. Not sure if it's appropriate to use that when running the tests, though. There's a related hack to inherit HOME in some circumstances.
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.
In the test environment, we cannot rely on this, though. 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.)
WDYT?
Thanks, Ludo’.
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?
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? Otherwise, we'd need some command line option to either enable inherit, or explicitly specify the value of PATH.
Regards, /Niels
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’.
ludo@gnu.org (Ludovic Courtès) writes:
No. I think tests should minimize assumptions about things that are outside of the build tree.
I see your point. But on the other hand, it's also desirable to test that the default PATH works (which it does on any "standard" system; maybe there's even some posix standard which formally mandates standard tools in /bin or /usr/bin?).
Another option would be to have the test environment define a custom HOME and provide an appropriate $HOME/.profile. Thoughts?
That could work. I think all tests do use a custom HOME for the user processes spawned by lshd. Whether or not $HOME/.profile works will depend on the login shell used, though. We could try overriding the login shell to always be /bin/sh or /bin/bash, I guess. Or set it to a wrapper which setsup the correct PATH.
I don't remember off the top of my head how you configure the login shell, possibly SHELL is inherited in the tests, just like HOME, or if there's some command-line option.
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.
I think such an option makes sense. Not entirly sure I want to use it in the tests by default, for the above reason: Then the default behaviour becomes untested.
Regards, /Niels