| Author |
Message |
< Erlang bugs mailing list ~ standard ssh to erlang sshd gives default shell, not the one |
| Guest |
 Posted: Mon Jul 26, 2010 3:32 pm |
 |
|
|
Guest
|
Hi,
Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
{shell, {Module, Function, Args}} in the proplist as its third parameter.
Everything works as expected if I just do (using openssh-5.5_p1, the current
version in Gentoo per this writing)
$ ssh -p<port> localhost
My shell is now invoked and is happily serving commands. Once I try the same
with a command-line parameter, i.e.,
$ ssh -p<port> localhost fafa
(expecting "fafa" to be passed to my shell function), the server hands "fafa"
over to the Erlang standard shell, which prints:
{error,{1,erl_parse,["syntax error before: ",[]]}}
And, logically, appending a dot to "fafa" makes it a valid Erlang expression,
which gets me a nice
fafa
The expected behaviour is that sshd accept the command and feed it to the
custom shell the user specified in the Options proplist.
This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in otp-14A.
All systems were tested on a Gentoo box (~amd64 arch), built from unpatched
sources from erlang.org.
Is this a bug, as I suppose it is?
Regards
Andrei Zavada
________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Aug 02, 2010 12:22 pm |
|
|
|
Guest
|
Hello!
Try something like:
Exec = {Module, Function, ArgList},
ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
Best regards,
Niclas @ Erlang/OTP
On Mon, 26 Jul 2010, andrei zavada wrote:
> Hi,
>
> Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
> {shell, {Module, Function, Args}} in the proplist as its third parameter.
>
> Everything works as expected if I just do (using openssh-5.5_p1, the current
> version in Gentoo per this writing)
>
> $ ssh -p<port> localhost
>
> My shell is now invoked and is happily serving commands. Once I try the same
> with a command-line parameter, i.e.,
>
> $ ssh -p<port> localhost fafa
>
> (expecting "fafa" to be passed to my shell function), the server hands "fafa"
> over to the Erlang standard shell, which prints:
>
> {error,{1,erl_parse,["syntax error before: ",[]]}}
>
> And, logically, appending a dot to "fafa" makes it a valid Erlang expression,
> which gets me a nice
>
> fafa
>
> The expected behaviour is that sshd accept the command and feed it to the
> custom shell the user specified in the Options proplist.
>
> This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in otp-14A.
> All systems were tested on a Gentoo box (~amd64 arch), built from unpatched
> sources from erlang.org.
>
> Is this a bug, as I suppose it is?
>
> Regards
> Andrei Zavada
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
>
________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Aug 03, 2010 2:58 pm |
|
|
|
Guest
|
Hi Niclas & all,
I gave it a try, and have a few things to note.
1. The exec option is not documented; it would be nice if it was.
2. Execution of command passed on ssh commandline is indeed suppressed if
ssh:daemon is started with an {exec, {M,F,A}} option. Plugging an empty
function as "F" could be a simple solution for the folks recently (rightly)
raising this as a security issue.
3. However, {exec, {M,F,A}} doesn't seem to work. Following your example, I
couldn't get my fun called. Looking into the sources in ssh_cli.erl, it
appears in this branch of handle_ssh_msg:
handle_ssh_msg({ssh_cm, ConnectionManager,
{exec, ChannelId, WantReply, Cmd}}, #state{exec=undefined} = State) -> {Reply, Status} =
exec(Cmd), write_chars(ConnectionManager,
ChannelId, io_lib:format("~p\n", [Reply])),
ssh_connection:reply_request(ConnectionManager, WantReply,
success, ChannelId),
ssh_connection:exit_status(ConnectionManager, ChannelId, Status),
ssh_connection:send_eof(ConnectionManager, ChannelId),
{stop, ChannelId, State#state{channel = ChannelId, cm = ConnectionManager}};
handle_ssh_msg({ssh_cm, ConnectionManager,
{exec, ChannelId, WantReply, Cmd}}, State) ->
NewState = start_shell(ConnectionManager, Cmd, State),
ssh_connection:reply_request(ConnectionManager, WantReply,
success, ChannelId),
{ok, NewState#state{channel = ChannelId,
cm = ConnectionManager}};
the second one, which is supposed to take effect when the user has supplied
an {exec, {M, F, A}} option, seems to never be reachable.
3. Down in start_shell and below, there is a call starting a group, similarly
to the way this is done for the regular, interactive shell. IMHO, if all I
need is connect via ssh, exec my command and return, a simple function call
will suffice.
4. In the context of the project I am fitting ssh into, I need to know who is
the user wanting to exec a command via ssh <host> <command>; hence, the
solution you pointed out with {exec, {M,F,A}}, isn't suitable. Even before, I
have prepared a patch (attached) for otp-13B04 to do exactly this. This
patch will, likely with some fuzz, apply to otp-14A as well.
With my patch, you would call ssh:daemon/3 with something like this in the
Options parameter:
Exec4User = fun(User, Cmd) -> do_something(User, Cmd), "Done" end,
ssh:daemon(Port, Address, {{exec4user, Exec4User} | OtherOptions}),
5. The solution I am proposing is of a "works-for-me" kind; someone has to
look into why the {exec, {M,F,A}} fails. In other words, there is little
sense for both exec and exec4user to coexist: let upstream decide.
Cheers,
Andrei Zavada
On Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
Niclas Eklund <nick@erix.ericsson.se> wrote:
>
> Hello!
>
> Try something like:
>
> Exec = {Module, Function, ArgList},
> ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
>
> Best regards,
>
> Niclas @ Erlang/OTP
>
> On Mon, 26 Jul 2010, andrei zavada wrote:
>
> > Hi,
> >
> > Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
> > {shell, {Module, Function, Args}} in the proplist as its third parameter.
> >
> > Everything works as expected if I just do (using openssh-5.5_p1, the
> > current version in Gentoo per this writing)
> >
> > $ ssh -p<port> localhost
> >
> > My shell is now invoked and is happily serving commands. Once I try the
> > same with a command-line parameter, i.e.,
> >
> > $ ssh -p<port> localhost fafa
> >
> > (expecting "fafa" to be passed to my shell function), the server hands
> > "fafa" over to the Erlang standard shell, which prints:
> >
> > {error,{1,erl_parse,["syntax error before: ",[]]}}
> >
> > And, logically, appending a dot to "fafa" makes it a valid Erlang
> > expression, which gets me a nice
> >
> > fafa
> >
> > The expected behaviour is that sshd accept the command and feed it to the
> > custom shell the user specified in the Options proplist.
> >
> > This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in
> > otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built
> > from unpatched sources from erlang.org.
> >
> > Is this a bug, as I suppose it is?
> >
> > Regards
> > Andrei Zavada
> >
> > ________________________________________________________________
> > erlang-bugs (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
> >
>
>
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 04, 2010 8:40 am |
|
|
|
Guest
|
Hello!
#1 It will be documented when it's supported.
#2 Will be considered.
#3 Use the following trace to confirm that your callback module is called:
dbg:tracer().
dbg:p(all, [call]).
dbg:tpl(group,start, [{'_',[],[{return_trace}]}]).
dbg:tpl(group,start_shell1, [{'_',[],[{return_trace}]}]).
If Exec == {shell, start, ["foo"]} and you run 'ssh -p 9999 localhost bar'
you should see:
(<0.68.0>) call group:start_shell1(shell,start,["foo","bar"])
#4 The exec option will perhaps be extended with similar options that
shell accepts.
Best regards,
Niclas @ Erlang/OTP
On Tue, 3 Aug 2010, andrei zavada wrote:
> Hi Niclas & all,
>
> I gave it a try, and have a few things to note.
>
> 1. The exec option is not documented; it would be nice if it was.
>
> 2. Execution of command passed on ssh commandline is indeed suppressed if
> ssh:daemon is started with an {exec, {M,F,A}} option. Plugging an empty
> function as "F" could be a simple solution for the folks recently (rightly)
> raising this as a security issue.
>
> 3. However, {exec, {M,F,A}} doesn't seem to work. Following your example, I
> couldn't get my fun called. Looking into the sources in ssh_cli.erl, it
> appears in this branch of handle_ssh_msg:
>
> handle_ssh_msg({ssh_cm, ConnectionManager,
> {exec, ChannelId, WantReply, Cmd}}, #state{exec=undefined} = State) -> {Reply, Status} =
> exec(Cmd), write_chars(ConnectionManager,
> ChannelId, io_lib:format("~p\n", [Reply])),
> ssh_connection:reply_request(ConnectionManager, WantReply,
> success, ChannelId),
> ssh_connection:exit_status(ConnectionManager, ChannelId, Status),
> ssh_connection:send_eof(ConnectionManager, ChannelId),
> {stop, ChannelId, State#state{channel = ChannelId, cm = ConnectionManager}};
>
> handle_ssh_msg({ssh_cm, ConnectionManager,
> {exec, ChannelId, WantReply, Cmd}}, State) ->
> NewState = start_shell(ConnectionManager, Cmd, State),
> ssh_connection:reply_request(ConnectionManager, WantReply,
> success, ChannelId),
> {ok, NewState#state{channel = ChannelId,
> cm = ConnectionManager}};
>
> the second one, which is supposed to take effect when the user has supplied
> an {exec, {M, F, A}} option, seems to never be reachable.
>
> 3. Down in start_shell and below, there is a call starting a group, similarly
> to the way this is done for the regular, interactive shell. IMHO, if all I
> need is connect via ssh, exec my command and return, a simple function call
> will suffice.
>
> 4. In the context of the project I am fitting ssh into, I need to know who is
> the user wanting to exec a command via ssh <host> <command>; hence, the
> solution you pointed out with {exec, {M,F,A}}, isn't suitable. Even before, I
> have prepared a patch (attached) for otp-13B04 to do exactly this. This
> patch will, likely with some fuzz, apply to otp-14A as well.
>
> With my patch, you would call ssh:daemon/3 with something like this in the
> Options parameter:
>
> Exec4User = fun(User, Cmd) -> do_something(User, Cmd), "Done" end,
> ssh:daemon(Port, Address, {{exec4user, Exec4User} | OtherOptions}),
>
> 5. The solution I am proposing is of a "works-for-me" kind; someone has to
> look into why the {exec, {M,F,A}} fails. In other words, there is little
> sense for both exec and exec4user to coexist: let upstream decide.
>
> Cheers,
> Andrei Zavada
>
>
> On Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
> Niclas Eklund <nick@erix.ericsson.se> wrote:
>
>>
>> Hello!
>>
>> Try something like:
>>
>> Exec = {Module, Function, ArgList},
>> ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
>>
>> Best regards,
>>
>> Niclas @ Erlang/OTP
>>
>> On Mon, 26 Jul 2010, andrei zavada wrote:
>>
>>> Hi,
>>>
>>> Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
>>> {shell, {Module, Function, Args}} in the proplist as its third parameter.
>>>
>>> Everything works as expected if I just do (using openssh-5.5_p1, the
>>> current version in Gentoo per this writing)
>>>
>>> $ ssh -p<port> localhost
>>>
>>> My shell is now invoked and is happily serving commands. Once I try the
>>> same with a command-line parameter, i.e.,
>>>
>>> $ ssh -p<port> localhost fafa
>>>
>>> (expecting "fafa" to be passed to my shell function), the server hands
>>> "fafa" over to the Erlang standard shell, which prints:
>>>
>>> {error,{1,erl_parse,["syntax error before: ",[]]}}
>>>
>>> And, logically, appending a dot to "fafa" makes it a valid Erlang
>>> expression, which gets me a nice
>>>
>>> fafa
>>>
>>> The expected behaviour is that sshd accept the command and feed it to the
>>> custom shell the user specified in the Options proplist.
>>>
>>> This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in
>>> otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built
>>> from unpatched sources from erlang.org.
>>>
>>> Is this a bug, as I suppose it is?
>>>
>>> Regards
>>> Andrei Zavada
>>>
>>> ________________________________________________________________
>>> erlang-bugs (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
>>>
>>
>>
>
>
________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| wailian |
| Posted: Tue Mar 20, 2012 2:46 am |
|
|
|
Guest
|
| One of them is the Ugg bailey button boot which has classic and uniquely designed buttons on its body to give that elegant and luxurious look. It has a fantastic look and this includes the Bailey Triplet Boot which has 3 buttons. These boots have a shaft (the upper part of the boot) which can be turned up or turned down depending upon your need. These buttons are both for style or decoration along with being functional or usable as well. |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
