bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] Present libshishi support.


From: Mats Erik Andersson
Subject: Re: [bug-inetutils] Present libshishi support.
Date: Wed, 8 Aug 2012 17:03:30 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

onsdag den  8 augusti 2012 klockan 12:54 skrev Simon Josefsson detta:
> Mats Erik Andersson <address@hidden> writes:
> 
> > Hello all,
> >
> > let me spend a few short words on the present status
> > of libshishi Kerberos support within Inetutils:
> 
> Thank you for summarizing.  Do you think a public test server would be

In the meantime I have solved all issues except the ones
on OpenSolaris, which are cause by my inability to convince
login(1) to accept a pre-authenticated invokation. This hits
telnetd as well as rlogind, but all matters relating to libshishi
are working correctly as far as I now know. The recent "k5login"
authorization has only been run on GNU/Linux, though.

The utilities in large are tested also on FreeBSD and NetBSD.
On DragonFly BSD the prepackaged libshishi is stumbeling on
segfaults in one of libidn, libgpg-error, libgcrypt, libgnutls,
so I have not come to test there any Kerberized code.


Let me therefore continue to mention imaginable additions
to our present state:

   * I will rename the option 

         --servername=localhost

     as

         --server-name=localhost

     in order to comply with the naming in Shishi.
     Momentarily this concerns rshd and rlogind.
     Should also telnetd offer this switch?

   * Could the above be extended to allow

         address@hidden

     or even

         --server-name=rsh/address@hidden

     with increasing degree of replacing the default

            host/address@hidden   ?

   * In non-Kerberized setting there is "-l/--no-rhosts"
     to depreciate the equivalence file "$HOME/.rhosts".
     Should we introduce "--no-k5login" for the Kerberized
     setting, or could the old switches be overloaded to
     disable access to "$HOME/.k5login" for a server running
     a Kerberized service? Should we introduce "--no-basic-auth"
     to disable authorization type "basic"?

   * [Important] We must thoroughly test and evaluate the
     intended distinctions between

         telnetd -k -a off

         telnetd -k -a none

         telnetd -k -a user

         telnetd -k -a valid

     making sure that they land accurately at the intended
     authorization level. The latter two are to be given
     priority on behalf of our users.

In the longer perspective, two coding efforts are welcome:

   * Extend rcp with encryption, as authentication was
     implemented by myself earlier this summer.

   * Making ftp and ftpd able to use libshishi would make
     GNU Inetutils a strong collection of utilities!

Best regards,

  Mats



reply via email to

[Prev in Thread] Current Thread [Next in Thread]