Klish password protected view

1,202 views
Skip to first unread message

Goran

unread,
Nov 18, 2010, 8:14:11 AM11/18/10
to klish
Hello!

In my code there are many views and I would like the user to enter a
password, if he would want to get from "root-view" to "enable-
view" (the only next view possible from root view in my CLI). Than no
further passwords would be needed. (configure-view, diagnostics-view
etc)

I have tried many ways including xml without view="" parameter and
than calling my own builtin function but don't know how to enter a
specific view. I tried this code

/*shell_execute.c*/
static bool_t cliPassword(clish_shell_t *this, const lub_argv_t
*argv)
{
char password[BUFFER_VX_SIZE];
clish_view_t *view;
int depth = 0;

tinyrl_printf(this->tinyrl,"Enter password:");
gets(password);
if(strcmp(password,"admin")==0)
{
depth=clish_view__get_depth(this->view);
depth++;
view = clish_shell__get_pwd_view(this, depth);
this->view = view;
}
else
tinyrl_printf(this->tinyrl,"Incorrect password\n");

return BOOL_TRUE;
}

but it doesn't seem to be working

Any help would be appreciated.

Pkun

unread,
Nov 18, 2010, 8:57:59 AM11/18/10
to kl...@googlegroups.com
Hi

Why don't you want to use schema from xml-examples?

        <COMMAND name="enable"
                help="Turn on privileged commands"
                lock="false">
                <ACTION>su -l -c "clish -x /etc/clish-enable"</ACTION>
        </COMMAND>






2010/11/18 Goran <goran....@gmail.com>

Goran

unread,
Nov 18, 2010, 8:59:27 AM11/18/10
to klish
I solved the problem;

this is the XML (in root view)

<COMMAND
name="enable"
help="Enter the enable view">
<ACTION builtin="cliPassword"></ACTION>
</COMMAND>


this is the code: (shell_execute.c)

static bool_t cliPassword(clish_shell_t *this, const lub_argv_t
*argv)
{
char password[BUFFER_VX_SIZE];
clish_view_t *view = NULL;
const char *view_next = "enable-view";

tinyrl_printf(this->tinyrl,"Enter password:");
gets(password);
if(strcmp(password,"admin")==0)
{
view = clish_shell_find_create_view(this,view_next,NULL);
this->view = view;
}
else
tinyrl_printf(this->tinyrl,"Incorrect password\n");

return BOOL_TRUE;

Goran

unread,
Nov 18, 2010, 9:01:10 AM11/18/10
to klish
Because I am working on vxworks, and I have to use builtin functions

On 18 nov., 14:57, Pkun <serj.kalic...@gmail.com> wrote:
> Hi
>
> Why don't you want to use schema from xml-examples?
>
>         <COMMAND name="enable"
>                 help="Turn on privileged commands"
>                 lock="false">
>                 <ACTION>su -l -c "clish -x /etc/clish-enable"</ACTION>
>         </COMMAND>
>
> 2010/11/18 Goran <goran.gra...@gmail.com>

Pkun

unread,
Nov 18, 2010, 9:10:59 AM11/18/10
to kl...@googlegroups.com
May be it's better to change uid within your builtin function? I mean the unprivileged commands (builtin or external) don't need the privileges i.e. use privrleged user only when it's really needed.

2010/11/18 Goran <goran....@gmail.com>

cpatt...@globalgossip.net

unread,
Oct 3, 2013, 6:35:56 PM10/3/13
to kl...@googlegroups.com
Hello,
 I am trying to restrict users access to configure mode, but i want the non-privileged user to still be able to run the "#show running-config" and see the output. I have tried this in several different ways, but I cannot make heads or tails of a way to achieve this result.
First I tried putting a view restriction on the configure mode:

              <COMMAND name="configure"
                        help="Enter the configure view"
                        access="root"/>

                <COMMAND name="configure terminal"
                        help="Configure from the terminal"
                        view="configure-view"
                        access="root"
                        lock="true"/>

If I run clish as any other user, they cannot gain accesss to configure mode, but they also cannot see running config. They get this error:
localhost.localdomain#show running-config
Cannot write to the running-config.
The error while request to the config daemon.

I have to run the daemon like this in order for the privilege levesl to seem to work:
root                 12647     1  0 15:50 ?        00:00:00 konfd -u root
privilegeduser   12693     1  0 15:51 ?        00:00:00 konfd -u privilegeduser
nonprivileged    12767     1  0 15:53 ?        00:00:00 konfd -u nonprivileged



But this just doesn't seem correct, and you have stated that the proper way to do it is as above:

                <COMMAND name="enable"
                        help="Turn on privileged commands"
                        lock="false"
                        interrupt="true"
                        view="enable-view"
                        viewid="enable">
                        <ACTION>
                                su -l -c "clish -x /etc/clish-enable"
                        </ACTION>
                </COMMAND>

This seems to work fine, except for one major caveat; when I enter "#quit" or "#exit" it leaves the 'enabled' clish shell back into the original clish shell. Maybe this wouldn't be that bad, except that I get no prompt, and entering the "#?" command only show commands from the global-view.xml.

I cannot seem  to get a graceful exit. These ae the global-view.xml commands:

        <COMMAND name="quit"
                help="Logout of the current CLI session"
                lock="false">
                <ACTION builtin="clish_close"/>
        </COMMAND>
<!--=======================================================-->
        <COMMAND name="exit"
                help="Exit from this mode"
                lock="false">
                <ACTION builtin="clish_nested_up"/>
        </COMMAND>

Please guide me on the correct way to achieve this. Thanks in advance.

serj.k...@gmail.com

unread,
Oct 4, 2013, 3:44:44 AM10/4/13
to kl...@googlegroups.com
Hello

We have solved this problem by sudo utility and NAMESPACEs.
The priviledged mode (enable mode) is implemented in standard way (using su and executing new clish process). But "show running-config" command is defined in separate XML file in separate VIEW. Then this file is used by both priviledged and unpriviledged modes. The VIEW (with show running-config) is included to main VIEWs by NAMESPACE tag.

The "show running-config" command use sudo utility to get superuser privilegies and so succesfully connect to konfd daemon. The sudo utility has rich config file syntax to limit sudo operations by operations  you want (execution of konf utility only for example).

Probably the ideal solution is to create additional unix socket with read-only access in konfd daemon. So everybody can read config but only priviledged user can change config via another socket. But it's not implemented now. I think the sudo solution is rather good because we can use this mechanism for another information commands that need priveledged access.

04.10.2013 02:35, cpatt...@globalgossip.net пишет:
-------------------------------------------------

IMPORTANT NOTICE: The information in this email is confidential and may also be privileged. 
If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this email is unauthorised and strictly prohibited.  If you have received this email in error, please promptly inform us by reply email or telephone.  You should also delete this email and destroy any hard copies produced.
--
You received this message because you are subscribed to the Google Groups "klish" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

cpatt...@globalgossip.net

unread,
Oct 4, 2013, 6:04:23 PM10/4/13
to kl...@googlegroups.com
Thank you very much for the speedy response, and following your advice, I was able to get non-priveleged users to see the running-config by issuing "#sudo konf -- -d". However I still don't know how to get the around the "2 shells" issue: that is when the privileged user opens a second shell by issuing the "su -l -c "clish -x /etc/clish-enable", then quits, with the builtin ACTION "clish_close", they get back to a shell with no command prompt and can only type global commands. 

What is the best way to close the shell that opened with the  "su -l -c "clish -x /etc/clish-enable"?

thanks again

On Friday, October 4, 2013 1:44:44 AM UTC-6, Serj Kalichev wrote:
Hello

We have solved this problem by sudo utility and NAMESPACEs.
The privileged mode (enable mode) is implemented in standard way (using su and executing new clish process). But "show running-config" command is defined in separate XML file in separate VIEW. Then this file is used by both privileged and unprivileged modes. The VIEW (with show running-config) is included to main VIEWs by NAMESPACE tag.

The "show running-config" command use sudo utility to get superuser privileges and so successfully connect to konfd daemon. The sudo utility has rich config file syntax to limit sudo operations by operations  you want (execution of konf utility only for example).

Probably the ideal solution is to create additional unix socket with read-only access in konfd daemon. So everybody can read config but only privileged user can change config via another socket. But it's not implemented now. I think the sudo solution is rather good because we can use this mechanism for another information commands that need privileged access.


04.10.2013 02:35, cpatt...@globalgossip.net пишет:
Hello,
 I am trying to restrict users access to configure mode, but i want the non-privileged user to still be able to run the "#show running-config" and see the output. I have tried this in several different ways, but I cannot make heads or tails of a way to achieve this result.
First I tried putting a view restriction on the configure mode:

              <COMMAND name="configure"
                        help="Enter the configure view"
                        access="root"/>

                <COMMAND name="configure terminal"
                        help="Configure from the terminal"
                        view="configure-view"
                        access="root"
                        lock="true"/>

If I run clish as any other user, they cannot gain access to configure mode, but they also cannot see running config. They get this error:
localhost.localdomain#show running-config
Cannot write to the running-config.
The error while request to the config daemon.

I have to run the daemon like this in order for the privilege levels to seem to work:

serj.k...@gmail.com

unread,
Oct 5, 2013, 5:57:15 AM10/5/13
to kl...@googlegroups.com
Actually I don't understand the problem. Like a cisco we have non-priviledged mode (i call it "info" mode) and priviledged mode.
There is two way to get to priviledged mode. The first is to login as priviledged user (root or adm). This adm has a clish wrapper script as his shell in /etc/passwd. This wrapper script execute clish with path to XML with priviledged commands. Non-priviledged user ("cli" for example) has another wrapper script as his shell. This wrapper scripts execute clish with path to unpriviledged commands.

I have three dirs in etc. They are clish-xml (all XMLs), clish (symlinks to ../clish-xml/somethin.xml - non-priviledged commands) and clish-enable (symlinks to priviledged commands).
So then adm login itself - the exit command will lead to login again.

The second way to get into enable-mode is login as cli and then type "enable". This command execute "su ....". Actually it lead to fork(), exec() and then parent wait() for created process. When adm type "exit" the priviledged process aborts and parent unblocks. The normal execution of non-priviledged clish continues. It has prompt and etc. It has prompt because "enable" command is contained in some "info-view" - default unpriviledged view but not a part of global commands space (without VIEW at all).

05.10.2013 02:04, cpatt...@globalgossip.net пишет:

cpatt...@globalgossip.net

unread,
Oct 16, 2013, 6:43:35 PM10/16/13
to kl...@googlegroups.com
Serj,
 thanks for all your help. With your guidance I was able to figure out that I just wasn't using the "depth" tags properly; in fact I wasn't using them at all. Now I have added an incremental  "depth" tag to each view, and it all works just fine and as expected. 

Thanks again
Reply all
Reply to author
Forward
0 new messages