Thread

  1. Kerberos 5 breakage.

    Matthew N. Dodd <winter@jurai.net> — 1998-05-18T19:48:50Z

    It appears that compiling with Kerberos 5 support turned on against MIT
    Kerberos 1.0.5 produces some breakage.
    
    Anyone seen this?
    
    (I'm keen to use Kerberos 5 as its a deployed company wide and Sybase does
    not support it so it would make PostgreSQL look really good if this
    worked.)
    
    /* 
       Matthew N. Dodd		| A memory retaining a love you had for life	
       winter@jurai.net		| As cruel as it seems nothing ever seems to
       http://www.jurai.net/~winter | go right - FLA M 3.1:53	
    */
    
    
    
  2. Re: [HACKERS] Kerberos 5 breakage.

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-19T18:25:00Z

    > 
    > 
    > It appears that compiling with Kerberos 5 support turned on against MIT
    > Kerberos 1.0.5 produces some breakage.
    > 
    > Anyone seen this?
    > 
    > (I'm keen to use Kerberos 5 as its a deployed company wide and Sybase does
    > not support it so it would make PostgreSQL look really good if this
    > worked.)
    > 
    
    Last I heard, Kerberos worked, but that was a while ago.  Feel free to
    send in some patches.
    
    -- 
    Bruce Momjian                          |  830 Blythe Avenue
    maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
      +  If your life is a hard drive,     |  (610) 353-9879(w)
      +  Christ can be your backup.        |  (610) 853-3000(h)
    
    
  3. Re: [HACKERS] Kerberos 5 breakage.

    Matthew N. Dodd <winter@jurai.net> — 1998-05-19T18:30:42Z

    On Tue, 19 May 1998, Bruce Momjian wrote:
    > Last I heard, Kerberos worked, but that was a while ago.  Feel free to
    > send in some patches.
    
    I've compiled with kerberos 4 compatibility mode libraries in kerberos 5
    and it appears to compile, link and run but I've not got a good testbed
    for kerberos 4.
    
    While Kerberos 5 authentication and authorization is nice, I'd like to
    investigate the possibility of adding encryption as well.
    
    I've got to complete the setup of a test enviornment for this before I can
    start on the code.
    
    /* 
       Matthew N. Dodd		| A memory retaining a love you had for life	
       winter@jurai.net		| As cruel as it seems nothing ever seems to
       http://www.jurai.net/~winter | go right - FLA M 3.1:53	
    */
    
    
    
  4. Re: [HACKERS] Kerberos 5 breakage.

    Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-20T17:03:31Z

    "Matthew N. Dodd" <winter@jurai.net> writes:
    
    > I've compiled with kerberos 4 compatibility mode libraries in kerberos 5
    > and it appears to compile, link and run but I've not got a good testbed
    > for kerberos 4.
    
    The Kerberos 4 stuff works fine with real Kerberos 4 libraries.
    
    > While Kerberos 5 authentication and authorization is nice, I'd like to
    > investigate the possibility of adding encryption as well.
    
    Absolutely.  This should be specified in the pg_hba.conf file, so that
    you could demand Kerberos authentication plus encryption for sensitive
    data.  When not demanded by pg_hba.conf, it should be a client option.
    
    -tih
    -- 
    Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"
    
    
  5. Re: [HACKERS] Kerberos 5 breakage.

    Matthew N. Dodd <winter@jurai.net> — 1998-05-20T18:02:08Z

    On 20 May 1998, Tom Ivar Helbekkmo wrote:
    > > While Kerberos 5 authentication and authorization is nice, I'd like to
    > > investigate the possibility of adding encryption as well.
    > 
    > Absolutely.  This should be specified in the pg_hba.conf file, so that
    > you could demand Kerberos authentication plus encryption for sensitive
    > data.  When not demanded by pg_hba.conf, it should be a client option.
    
    I read through the SSL patch and am convinced that we need a little more
    coherent arrangment of interface methods.  Allowing direct manipulation of
    the file descriptors is really going to make adding stuff like this (SSL,
    Kerb5 encryption etc) next to impossible.
    
    Take a look at Apache 1.2 vx. 1.3 for an idea of what I'm talking about.
    
    Also, allowing writes of single characters is bad; you incur a context
    switch each write.  The client and server should be writing things into
    largish buffers and writing those instead of doing small writes.
    
    The existence of the following scare me...
    
    pqPutShort(int integer, FILE *f)
    pqPutLong(int integer, FILE *f)
    pqGetShort(int *result, FILE *f)
    pqGetLong(int *result, FILE *f)
    pqGetNBytes(char *s, size_t len, FILE *f)
    pqPutNBytes(const char *s, size_t len, FILE *f)
    pqGetString(char *s, size_t len, FILE *f)
    pqPutString(const char *s, FILE *f)
    pqGetByte(FILE *f)
    pqPutByte(int c, FILE *f)
    
    (from src/backend/libpq/pqcomprim.c)
    
    A select based I/O buffering system would seem to be in order here...
    
    I'd like to see these routines passing around a connection information
    struct that contains the file handle and other connection options as well.
    
    I'll not bother beating on this anymore as I'm unlikely to cover anything
    that has not already been covered.  Regardless, this issue needs some
    critical analysis before any code is changed.
    
    Failing to address this issue really raises the cost of adding stuff like
    SSL and Kerberos5 encryption.
    
    Take a look at src/main/buff.c and src/include/buff.h in Apache 1.3 at how
    they use their 'struct buff_struct' for some interesting examples.
    
    /* 
       Matthew N. Dodd		| A memory retaining a love you had for life	
       winter@jurai.net		| As cruel as it seems nothing ever seems to
       http://www.jurai.net/~winter | go right - FLA M 3.1:53	
    */
    
    
    
  6. Re: [HACKERS] Kerberos 5 breakage.

    Henry B. Hotz <hotz@jpl.nasa.gov> — 1998-05-20T18:38:51Z

    At 11:02 AM -0700 5/20/98, Matthew N. Dodd wrote:
    >Also, allowing writes of single characters is bad; you incur a context
    >switch each write.  The client and server should be writing things into
    >largish buffers and writing those instead of doing small writes.
    >
    >The existence of the following scare me...
    >
    >pqPutShort(int integer, FILE *f)
    .
    .
    .
    
    Can't these be defined as macros the way get/put stuff is done in stdio.h?
    
    Signature failed Preliminary Design Review.
    Feasibility of a new signature is currently being evaluated.
    h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
    
    
    
    
  7. Re: [HACKERS] Kerberos 5 breakage.

    Matthew N. Dodd <winter@jurai.net> — 1998-05-20T18:46:59Z

    On Wed, 20 May 1998, Henry B. Hotz wrote:
    > Can't these be defined as macros the way get/put stuff is done in stdio.h?
    
    Which macros?
    
    Looking at stdio.h and the FILE struct/typedef; I wonder if its possible
    to override the _read and _write function pointers and sub in our own
    depending on when encryption scheme is in use.
    
    /* 
       Matthew N. Dodd		| A memory retaining a love you had for life	
       winter@jurai.net		| As cruel as it seems nothing ever seems to
       http://www.jurai.net/~winter | go right - FLA M 3.1:53	
    */
    
    
    
  8. Re: [HACKERS] Kerberos 5 breakage.

    Henry B. Hotz <hotz@jpl.nasa.gov> — 1998-05-20T21:15:57Z

    At 11:46 AM -0700 5/20/98, Matthew N. Dodd wrote:
    >On Wed, 20 May 1998, Henry B. Hotz wrote:
    >> Can't these be defined as macros the way get/put stuff is done in stdio.h?
    >
    >Which macros?
    >
    I haven't actually looked, but I think it's pretty standard for
    getchar/putchar to just do I/O from some local-to-the-program buffers.
    Only when they overflow does it become a real system/library call, but they
    look like function calls to the C program.
    
    It's also true that you can play games with incremental linking and symbol
    table stripping to insert your own wrapper on a system routine, but I would
    not recommend that.  It's much too likely to create portability problems.
    
    Signature failed Preliminary Design Review.
    Feasibility of a new signature is currently being evaluated.
    h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu