[tac_plus] Re: enable = file /etc/passwd

[Antonin Vitecek]

Dan Schmidt wrote:
> I am having the same problem as this user:
>
> http://www.shrubbery.net/pipermail/tac_plus/2007-February/000078.html
>
>  
>
> Is this a bug?  Terribly sorry if this has been talked about before - I
> could not seem to google it. 
>
>  
>
> Thanks, 
>
> -Dan 
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/fd30a19b/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
>   
Hi,

Jeff Gehlbach sent me a patch solving this problem, but format of his
patch didn't work to me, so I created new. There is mail from Jeff:

=================================================================================================

Hi!

I just ran across this same issue.  Sorry if my reply doesn't get
properly threaded, I'm pasting your message from the mailman archive as
I was not subscribed to the list at the time you sent it.

On Wed Feb 14 14:40:16 UTC 2007, Antonin Vitecek <AntoninVitecek at seznam.cz> wrote:


> > I have a little question. Is it possible authenticate enable password
> > using passwd(5) file? Because I found it on Shrubbery
> > page(http://www.shrubbery.net/tac_plus/) at the bottom:
> > 
> >  user = bar {
> >         enable = file /etc/tac_enable_pwd
> > }
> > 
> > But, if I try it, I get this message: 
> > 
> > 192.168.0.1: Error cannot identify password type file /etc/passwd for
> > john
> > 
> > For login it is ok. In pwlib.c I found: 
> > 
> >     /* Oops. No idea what kind of password this is. This should never
> >      * happen as the parser should never create such passwords. */
> > 
> > What I want is to have same login and enable password.
>   

I believe this may be a bug in the Shrubbery code.  I applied the
attached patch to the source as obtained by extracting
tacacs+-F4.0.4.14.tar.gz from ftp.shrubbery.net.  I can now use 'enable
= file /path/foo' with no issues.  I don't have a sufficiently deep
understanding of the TACACS+ protocol to know whether this will work in
every situation, but it got me running.  If anybody sees a problem with
this patch, please let me know.

The patch also adds single quotes around the parameterized strings in
the "Error cannot identify password type" messages, so that they read
e.g.:

Error cannot identify password type 'file' for 'john'

-jeff

*** pwlib.c.orig        2007-03-08 09:58:36.000000000 -0500
--- pwlib.c     2007-03-08 09:04:07.000000000 -0500
***************
*** 207,213 ****
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type %s for %s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 207,213 ----
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type '%s' for '%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
***************
*** 261,270 ****
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type %s for %s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 261,281 ----
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
+     p = tac_find_substring("file ", cfg_passwd);
+     if (p) {
+       if (!passwd_file_verify(name, passwd, data, p)) {
+           data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+           return(0);
+       } else {
+           data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
+       }
+       return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
+     }
+ 
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type '%'s for '%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");


=================================================================================================



-------------- next part --------------
A non-text attachment was scrubbed...
Name: tac_plus_enable_passwdfile_new.patch
Type: text/x-patch
Size: 1472 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20070911/999a7086/attachment.bin