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: