Re: *term -ls, a summary
>>>>> "Norbert" == Norbert Veber <nveber@debian.org> writes:
Since I'm the one who originally post the message, I think I should make
some comments about these.
>> How is this case different from, say, executing a program off a menu
>> in X? Last time I checked, you also don't get your .profile files
>> read, _unless_ you source them from your ~/.xsession (which is
>> precisely what that file is for).
Norbert> The difference is that ssh runs a shell, while X runs a window
Norbert> manager..
Consider pdmenu. If one runs a program in X using pdmenu, X has already
created the login environment, so there is no need to re-initialize things.
Pdmenu will spawn a subshell using fork(), and all the environment (e.g.,
environment variables, current directory, umask, limits, etc) will be
inherited. If you runs ssh and interactively login from another machine,
then run pdmenu from there, then the interactive ssh shell that ssh creates
has created the login environment, so there is no need to re-initialize
things. So basically, pdmenu is always executed from a place where the
login environment is already initialized, so pdmenu has no business to
source .profile.
Running a program in X using its menu is just the same as the first case:
the X session manager has already initialized the login environment, which
eventually use fork() to run the window manager. So the window manager
inherit the login environment. Now when you use the menu to run a command,
it calls fork(), and the resulting command also inherit the environment from
the window manager. So in any case, choosing the menu shouldn't result in
sourcing .profile before running anything.
The exception is, of course, what Norbert filed a report for: if you run ssh
from remote non-interactively and execute pdmenu (or whatever other
programs), you will be executing in a place where no login environment has
been executed. It is clear that ssh is broken here: it allows a path of
user program execution that no initialization has been executed. (How to
generalize this? See the end of this post.)
Note that what this bug report aims for is a *lack of* special case.
Whenever I run a program as user, I want to be sure that I've inherited some
login environment from some program that I've executed before, and that I've
established that environment only once from the path that where the "init"
program starts. Yes, you may execute ssh non-interactively and use a
~/.ssh/environment, which will then create an environment. But interactive
login shell still use .ssh/environment, and then .profile. So the login
environment will be created twice. You end up having to treat "running ssh
interactive, so .ssh/environment has already been executed" as a special
case in your .profile, to make sure that additional change of PATH (e.g.,
appending ~/bin into PATH), etc., won't happen.
Ian> The concept of a "login shell" should continue to refer to its
Ian> common-sense meaning, rather then inventing a new meaning for it
Ian> just for implementation convenience.
The problem is, there is *no* commonly agreed upon "common sense meaning" of
a login shell that works well in practice. We really need to define one.
Ian> Yes. IMO login => interactive.
This does not work well in practice, since then nothing else will be able to
make sure that your environment is properly set.
Ian> Why couldn't you have a "ssh -c command" in .xsession, for example?
Ian> I can imagine some quite practical uses for that.
Hm... in ssh, -c means choose a cipher. Perhaps you mean "ssh host command"
instead. And I think this is the core problem: the "command" is not
executed in a pre-defined, user-controllable environment. Indeed, there is
no flag in the ssh client that asks the server to create such an
environment. This is completely determined by the existence or absence of
the "command" argument. Which is completely broken.
Ian> Why do we have .bashrc and .bash_profile then? Have you filed a
Ian> bug against bash already?
No. You can type "bash" to execute a new shell, and in this case the whole
login environment is inherited from your previous login shell.
Ian> Executing a command in an authenticated fashion is not a session.
Ian> Another analogy: su -c command. Also doesn't read root's (or the
Ian> target user's) profile.
Yes, that can be a special case. But as every sys-admin will be happy to
tell you, they always type "su - ..." rather than "su ..." (because the user
might have set his own PATH variable to trick your su-executed command to
run the wrong command, directly or indirectly). Note that "-" creates a
login shell. While this is a fundamental mis-design (the most frequently
needed, safe case needs more typing), users generally live with the
mis-design, simply remember to always type "-", as it is convenient enough.
Where is the easy ssh way to say "I want you to establish a complete session
in the server"?
That ssh is special is because when you type "ssh host ...", you are not
"forking" out a program from any old process of the user. Instead, the new
process is forked out by the ssh server, which has no environment of its own
(it has one, but it is not the environment of the user, and thus is unsafe
to be used by the user). Note that *what* ssh does is not the reason why I
want it to establish a session. The problem is really that the user running
ssh is not the user who created the resulting process (root fork() that
out). If you find another program which has similar behaviour (ftp is
perhaps a good choice in case it runs a program, but nobody use that so
there is really no problem there), that is broken, too.
Regards,
Isaac.
Reply to: