On Wed, Oct 13, 2010 at 2:13 AM, Robert Haas <robertmh...@gmail.com> wrote: > 2010/8/24 KaiGai Kohei <kai...@ak.jp.nec.com>: >> I tried to revise the patch. It allows plugins to get control next to >> client authentication, but before returning the status to users. >> >> This change enables plugins which should be invoked on authentication >> failed to utilize this hook, not only assignment of session security >> label. >> At the same time, it disables to hook on SET SESSION AUTHORIZATION. >> But it is a bit unclear whether we should hook here, or not. > > Stephen - > > You've been listed as a reviewer for this in the CF app since 9/17 - > are you planning to review it?
I guess not. I took a brief look at this tonight, and it seems to me that it still fails the test I proposed nearly two months ago: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01458.php KaiGai responded with: > If and when a connection came from a host but we don't accept the > delivered security label, or labeled networking is misconfigured, > getpeercon(3) returns NULL. In this case, server cannot identify > what label should be applied on the client, then, we should > disconnect this connection due to the error on database login, > not any access control decision. > > In similar case, psm_selinux.so disconnect the connection when > it cannot identify what security label shall be assigned on the > session, due to some reasons such as misconfigurations. > > Without any hooks at authorization stage (but it might be different > place from this patch, of course), we need to delay the error > handling by the time when SE-PostgreSQL module is invoked at first. > But it is already connection established and user sends a query. > It seems to me quite strange behavior. I don't find this very convincing. We are still several patches from having a working SE-PostgreSQL module, and I think we should be worried about getting off the ground before we worry about this sort of fine-tuning. I don't see reporting an SE-PostgreSQL error slightly sooner is worth a separate hook, especially given that we're still several patches from having even a toy SE-PostgreSQL implementation. For example, we may find that some other hook that is more certainly necessary can also serve the purpose intended for this one. And later with: > Yes, I also think this kind of authorization hook should benefit other > applications, not only label based mac features. > > For example, something like 'last' command in operations system which > records username and login-time. Stephen mentioned pam_tally that locks > down certain accounts who failed authentication too much. > Perhaps, PAM modules in operating system give us some hints about other > possible applications. This is closer to the mark, but mostly speculative, and not detailed enough to determine whether the proposed hook is properly located. It seems rather early to me: this is before we've sent the authentication packet to the client, so we couldn't, for example, log the success or failure of the authentication; we don't know whether it will succeed or fail. I am going to mark this Returned with Feedback. I would like to request that any future submissions to add a hook in this area be accompanied by a working sample contrib module that is not SE-Linux specific. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
