Re: RADIUS authentication - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: RADIUS authentication
Date
Msg-id 9837222c1001190719i1dc63b19oad689d2b03cda9b1@mail.gmail.com
Whole thread Raw
In response to Re: RADIUS authentication  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: RADIUS authentication
Re: RADIUS authentication
List pgsql-hackers
2010/1/18 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> (2010/01/10 22:25), Magnus Hagander wrote:
>> The attached patch implements RADIUS authentication (RFC2865-compatible).
>>
>> The main usecase for me in this is the ability to use (token based)
>> one-time-password systems easily with PostgreSQL. These systems almost
>> always support RADIUS, and the implementation is fairly simple. RADIUS
>> can of course be used in many other scenarios as well (for example, it
>> can be used to implement "only this group"-access with at least Active
>> Directory, something our current LDAP doesn't support. We might
>> eventually want to support that in our LDAP, but it's not there now)
>
> I checked this patch.

Thanks!


> Here is a few comments from the initial reviewing.
>
> * Is the feature to be configurable via ./configure scripts?
>  Currently, we have --with-pam or --with-ldap option, and it allows
>  users to turn on/off the feature.
>  Of course, it has dependency on libraries.

I think not, because it doesn't rely on external libraries we might as
well always enable it. As long as you don't configure it in
pg_hba.conf, it has zero cost to the installation. Adding a configure
parameter would just make things complicated. For example, we don't
have a configure switch to enable ident or md5.


> * A corresponding comment. This patch implements RADIUS protocol
>  by itself. Is there any commonly used libraries for the purpose?
>  It allows us to separate a burden to manage a certain network
>  protocol within PostgreSQL.

I looked briefly at it. The ones I found would require almost as much
code as doing the protocol itself, and had some compatibility issues
(mainly wrt windows)


> * IIUC, inet_addr() takes only IPv4 address. It is used to translate
>  "radiusserver" parameter to netaddr format.
>  Could you document this parameter takes only IPv4 format.

Will do.


> * I think this comment is right.
>  +   for (i = 0; i < RADIUS_VECTOR_LENGTH; i++)
>  +       /* XXX: Generate a more secure random string? */
>  +       packet->vector[i] = random() % 255;
>
>  The random seed is initialized at BackendRun() with MyProcPid and
>  the time of backend process launched.
>  Then, PostgresMain() -> InitPostgres() -> PerformAuthentication()
>  will be called, and this random() shall be the first call just after
>  initialization of the srandom().
>
>  Do you have any good idea?
>  Or, do you think it should be fixed with high priority?

It does need a fairly good random number generator there to be secure,
so it should probably be improved. OTOH, the whole thing can be more
considered obfuscation rather than encryption, and those who really
care about higher security will use ipsec or trusted networks.

Maybe switching to erand48() would make this better, and good enough?


> * It casts char array (such as radius_buffer) into radius_packet
>  structure. The radius_packet structure represents the format of
>  RADIUS network packet as is.
>  It may be preferable to give compiler a hint not to align this
>  structure.
>  In GCC, we can use "__attribute__((packed))" to suggest not to
>  align the member of structure. Is there any portable way for this?

This I can't answer, I don't know this well enough. Somebody else?


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: ioguix@free.fr
Date:
Subject: Bug ? different behaviour between 8.3 and 8.4 won IS NULL with sub arrays of nulls
Next
From: Tom Lane
Date:
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)