Project

General

Profile

Actions

Bug #4045

closed

vty: incomplete commands accepted in multi-choice token

Added by pespin almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
libosmovty
Target version:
-
Start date:
06/05/2019
Due date:
% Done:

100%

Spec Reference:

Description

See issue described in https://gerrit.osmocom.org/c/osmo-sgsn/+/14195

For example, the following command definition:

auth-policy (accept-all|closed|acl-only|remote)

actually permits the following variations:

  auth-policy accept-all
  auth-policy accept
  auth-policy acl
  auth-policy re
  auth-policy c

So it seems in those cases, the matched VTY command (the DEFUN function ) will be passed with the incomplete sting instead of the full accepted string (eg: "re" instead of "remote).

That must be avoided and once "re" is matched to be "remote", "remote" should be passed inside argv[] instead of "re". Otherwise complexity of VTY commands parsing grows incredibly and makes no sense to have that logic duplicated in every cmd.

Actions #1

Updated by pespin almost 5 years ago

  • Description updated (diff)
Actions #2

Updated by pespin almost 5 years ago

  • Assignee set to pespin

From fixeria :

 The problem is somewhere in cmd_execute_command_real(). Instead of composing 'argv' from 'vline', we need to use 'matched_element'.

Some info from gdb:
  $ gdb -q ./vty_transcript_test
  (gdb)$ b command.c:2322
  $ telnet localhost 42042
  $ vty_transcript_test> th
  (gdb)$ bt
    #0  cmd_execute_command_real (vline=0x62ac30, vty=0x6295e0, cmd=0x0) at command.c:2321
    #1  0x00007ffff7767575 in cmd_execute_command (vline=0x62ac30, vty=0x6295e0, cmd=0x0, vtysh=0x0) at command.c:2354
    #2  0x00007ffff776ab79 in vty_command (vty=0x6295e0, buf=0x629790 "multi0 th") at vty.c:431
    #3  0x00007ffff776b3a0 in vty_execute (vty=0x6295e0) at vty.c:695
    #4  0x00007ffff776cf8c in vty_read (vty=0x6295e0) at vty.c:1419
    #5  0x00007ffff776f5f1 in client_data (fd=0x629538, what=0x1) at telnet_interface.c:147
    #6  0x00007ffff7ba01c4 in osmo_fd_disp_fds (_rset=0x7fffffffda20, _wset=0x7fffffffdaa0, _eset=0x7fffffffdb20) at select.c:223
    #7  0x00007ffff7ba0349 in osmo_select_main (polling=0x0) at select.c:263
    #8  0x00000000004016d2 in main (argc=0x1, argv=0x7fffffffdcb8) at vty/vty_transcript_test.c:232
    #9  0x00007ffff73b3f45 in __libc_start_main (main=0x40154b <main>, argc=0x1, argv=0x7fffffffdcb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdca8) at libc-start.c:287
#10 0x00000000004010f9 in _start ()
  (gdb)$ p (char *) (vline->index[0])
    $131 = 0x62ad20 "multi0" 
  (gdb)$ p (char *) (vline->index[1])
    $132 = 0x62ad90 "th" 
  (gdb)$ p (char *) *((struct _vector *)((struct _vector *)((struct _vector *)(matched_element->strvec->index[0])))->index[0])
    $133 = 0x626400 "multi0" 
  (gdb)$ p (char *) *((struct _vector *)((struct _vector *)((struct _vector *)(matched_element->strvec->index[1])))->index[0])
    $134 = 0x626660 "one" 
  (gdb)$ p (char *) *((struct _vector *)((struct _vector *)((struct _vector *)(matched_element->strvec->index[1])))->index[1])
    $135 = 0x626390 "two" 
  (gdb)$ p (char *) *((struct _vector *)((struct _vector *)((struct _vector *)(matched_element->strvec->index[1])))->index[2])
    $136 = 0x626840 "three" 

fixeria also submitted a patch to showcase the issue in this libosmocore test:
https://gerrit.osmocom.org/c/libosmocore/+/14307/

Actions #3

Updated by pespin almost 5 years ago

Fixed what could be a related issue in here:
https://gerrit.osmocom.org/c/libosmocore/+/14422 vty: command.c: Fix is_cmd_ambiguous() returning always 0

But I don't think it's fixing the whole issue.

At least it finds some more ambiguous commands:

vty_transcript_test> multi0 t
% Ambiguous command.
Error during transcript step 6:
[
vty_transcript_test> multi0 t
ok argc=1 t
]
Error while verifying transcript file '/home/osmocom-build/jenkins/workspace/gerrit-libosmocore/a2/default/a3/default/a4/default/arch/amd64/label/osmocom-gerrit-debian9/tests/vty/vty_transcript_test.vty'
signal 15 received
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/osmopython-0.1.0-py3.5.egg/osmopy/osmo_interact/common.py", line 362, in verify_application
    interact.verify_transcript_file(transcript_file)
  File "/usr/local/lib/python3.5/dist-packages/osmopython-0.1.0-py3.5.egg/osmopy/osmo_interact/common.py", line 116, in verify_transcript_file
    result = self.verify_transcript(content)
  File "/usr/local/lib/python3.5/dist-packages/osmopython-0.1.0-py3.5.egg/osmopy/osmo_interact/common.py", line 205, in verify_transcript
    % (match_result, step, step.command_str(), '\n'.join(res)))
Exception: Result mismatch:
Mismatch:
Expect:
'ok argc=1 t'
Got:
'% Ambiguous command.'

Actions #4

Updated by pespin almost 5 years ago

  • Status changed from New to In Progress

I have a fix for this issue already in my pespin/vty branch, but I found a related issue for single-choice optional parameters, which is showcased in this test:
https://gerrit.osmocom.org/c/libosmocore/+/14431 vty: tests: Verify incomplete optional parameters are passed to vty funcs

Once I fix that issue (related code), then I'll submit fixes for both together.

Actions #5

Updated by pespin almost 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 90

Both issues should be fixed by:
https://gerrit.osmocom.org/c/libosmocore/+/14436 vty: command.c: Fix: multi-choice args are no longer passed incomplete to vty func
https://gerrit.osmocom.org/c/libosmocore/+/14437 vty: command.c: Fix: single-choice optional args are no longer passed to vty func

Once merged we can close the ticket.

Actions #6

Updated by pespin almost 5 years ago

  • Assignee changed from pespin to fixeria

Assigning to fixeria so he can check that initial issue found while using VTY is indeed fixed.

Actions #7

Updated by fixeria almost 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

I am happy to confirm that the problem has been resolved. No segfaults anymore. Thanks Pau!

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)