Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/07/09 23:52), Stephen Frost wrote: > * Stephen Frost (sfr...@snowman.net) wrote: >> Guess my first thought was that you'd have a database-level label that >> would be used by SELinux to validate a connection. A second thought is >> labels for roles. KaiGai, can you provide your thoughts on this >> discussion/approach/problems? I realize it's come a bit far-afield from >> your original proposal. > > Something else which has come up but is related is the ability to > support a "pam_tally"-like function in PG. Basically, the ability to > lock users out if they've had too many failed login attempts. I wonder > if we could add this hook (or maybe have more than one if necessary) in > a way to support a contrib module for that. > It seems to me a good idea. BTW, where do you intend to apply this "pam_tally" like functionality? If it tries to lock users out on the identification stage; like the pam_tally.so on operating systems, the hook should be placed on the top-half of ClientAuthentication(). On the other hand, when we tries to set up properties of a certain user's session, it needs to be placed on the authorization stage. In the PG code, InitializeSessionUserId() just performs the role to assign the authenticated user's identifier on the current session. It seems to me it is a candidate where we put a hook on the authorization stage. Of course, these are not exclusive. We can provide two hooks to provide a chance to get control on identification and authorization stages. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote: >> > Something else which has come up but is related is the ability to >> > support a "pam_tally"-like function in PG. Basically, the ability to >> > lock users out if they've had too many failed login attempts. I wonder >> > if we could add this hook (or maybe have more than one if necessary) in >> > a way to support a contrib module for that. >> >> Seems like the hard part would be figuring out where to store the >> bookkeeping information. > > pam_tally does it in a flat file on-disk. It's not perfect, but it > works. It'd be good enough for me if there was a hook in the right > place that I could write the contrib module. > > Of course, it'd be even nicer to have support for this in-core, since > it's a FISMA requirement and not everyone is going to like having to > install a contrib module to handle something like this. Feel free to propose a patch...! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote: > > Something else which has come up but is related is the ability to > > support a "pam_tally"-like function in PG. Basically, the ability to > > lock users out if they've had too many failed login attempts. I wonder > > if we could add this hook (or maybe have more than one if necessary) in > > a way to support a contrib module for that. > > Seems like the hard part would be figuring out where to store the > bookkeeping information. pam_tally does it in a flat file on-disk. It's not perfect, but it works. It'd be good enough for me if there was a hook in the right place that I could write the contrib module. Of course, it'd be even nicer to have support for this in-core, since it's a FISMA requirement and not everyone is going to like having to install a contrib module to handle something like this. Of course, so is stuff like remembering old passwords, password aging, etc... I do really wish there was a way PAM could be used by applications *independently* of the system auth (eg: /etc/passwd) to handle all of this. If anyone's aware of a way, I'm all ears.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote: > * Stephen Frost (sfr...@snowman.net) wrote: >> Guess my first thought was that you'd have a database-level label that >> would be used by SELinux to validate a connection. A second thought is >> labels for roles. KaiGai, can you provide your thoughts on this >> discussion/approach/problems? I realize it's come a bit far-afield from >> your original proposal. > > Something else which has come up but is related is the ability to > support a "pam_tally"-like function in PG. Basically, the ability to > lock users out if they've had too many failed login attempts. I wonder > if we could add this hook (or maybe have more than one if necessary) in > a way to support a contrib module for that. Seems like the hard part would be figuring out where to store the bookkeeping information. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* Stephen Frost (sfr...@snowman.net) wrote: > Guess my first thought was that you'd have a database-level label that > would be used by SELinux to validate a connection. A second thought is > labels for roles. KaiGai, can you provide your thoughts on this > discussion/approach/problems? I realize it's come a bit far-afield from > your original proposal. Something else which has come up but is related is the ability to support a "pam_tally"-like function in PG. Basically, the ability to lock users out if they've had too many failed login attempts. I wonder if we could add this hook (or maybe have more than one if necessary) in a way to support a contrib module for that. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/07/08 23:58), Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> I'm not sure what the best thing to do about this is. I think it >> might be a good idea to start with some discussion of what problems >> people are trying to solve (hopefully N> 1?) and then try to figure >> out what a good solution might look like. > > Guess my first thought was that you'd have a database-level label that > would be used by SELinux to validate a connection. A second thought is > labels for roles. KaiGai, can you provide your thoughts on this > discussion/approach/problems? I realize it's come a bit far-afield from > your original proposal. > Let's sort out the point at issues from perspective of the models. Please remind the authentication (in broad-sense) is consist of a few steps. 1) Identification In this step, system tries to obtain the identifier of client. Typically, it is a username provided using connection string in pgsql. 2) Authentication (in narrow-sense) In this step, system tries to verify whether the given identifier is correct, or not. Typically, it checks the password corresponding to the user. 3) Authorization In this step, system tries to assign a set of privileges on the new session. Typically, it is user identifier itself, because DAC makes access control decision based on the combination of user identifier and access control list of the objects. But all the security modules also intend to utilize the user identifier for its own access control decision. E.g, SELinux uses a security label of the client process. If we would have something like Oracle Label Security, client's label may be associated with a certain database role that is already authorized. The purpose of my patch was to provide an external security provider a chance to (3) authorize the new session based on or not-based on the (1) identification and (2) authentication. If we try to allow security providers to get control all of the 1-3, it might be hard to find the best place to put the hook right now. But, at least, SELinux does not have a plan to interpose identification and authentication. All I want to do here is to authorize the client just after authentication process. I'd like to suggest that we focus on the (3) authorization process for functionality of the patch. It may be also worth to control identification and authentication using security provider, but we don't have actual guest module right now. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* Robert Haas (robertmh...@gmail.com) wrote: > I'm not sure what the best thing to do about this is. I think it > might be a good idea to start with some discussion of what problems > people are trying to solve (hopefully N > 1?) and then try to figure > out what a good solution might look like. Guess my first thought was that you'd have a database-level label that would be used by SELinux to validate a connection. A second thought is labels for roles. KaiGai, can you provide your thoughts on this discussion/approach/problems? I realize it's come a bit far-afield from your original proposal. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
On Thu, Jul 8, 2010 at 10:48 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> I think we have to assume that whatever actions a pluggable security >> provider might take at authentication time are going to be based on >> information from outside the database. > > I feel that would be perfect for 9.1 and supporting access to the > general catalog is something that, if we figure out a sane way to > do it, we could always add later (if there's demand, etc). > > For those bits of the catalog which *do* meet the requirements you > mention, I hope it'll be possible for the security module to access > them? Does make me wonder if we might consider adding a field to those > to support a label rather than trying to figure out a way for a third > party to provide a shared/nailed relation. I'm not sure what the best thing to do about this is. I think it might be a good idea to start with some discussion of what problems people are trying to solve (hopefully N > 1?) and then try to figure out what a good solution might look like. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* Robert Haas (robertmh...@gmail.com) wrote: > I think we have to assume that whatever actions a pluggable security > provider might take at authentication time are going to be based on > information from outside the database. I feel that would be perfect for 9.1 and supporting access to the general catalog is something that, if we figure out a sane way to do it, we could always add later (if there's demand, etc). For those bits of the catalog which *do* meet the requirements you mention, I hope it'll be possible for the security module to access them? Does make me wonder if we might consider adding a field to those to support a label rather than trying to figure out a way for a third party to provide a shared/nailed relation. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Maybe so, but the proposed hook placement doesn't actually allow a > plugin module to be "involved" in the authorization --- we've already > decided the authorization is OK. All it can do there is some additional > initialization, which could equally well be done on first use (if any) > of the additional information. Right, I agree that the existing patch isn't what should be done here. > There might be some value in letting a plugin actually have some control > over the authentication process, but I'm not sure offhand what a > reasonable hook design would be. Definitely needs more thought, but that's the direction that I think makes more sense. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost wrote: >> FWIW, I am still of the opinion that we shouldn't have a hook here >> anyway, because there is no reason to complain about lack of a >> security context until the user performs an action which requires them >> to have a security context. > > I don't agree with this, in general. It may be a difficult problem to > solve though. From my perspective the above is similar to saying we > don't need a pg_hba.conf or that we should open a database before > checking the user's credentials. I'd like to give a security module the > ability to be involved in the initial connection authorization, but we > run into an issue there if that module then needs access to the catalog. > Perhaps it doesn't, but it seems like it would, to use to make a > decision. Well, perhaps I'll revise my opinion here a bit. If we're actually going to do something with the user's security context at connection time, like validate that they have rights to connect to the database they've selected, then it would make sense to have a hook somewhere in the authentication process. I think we have to assume that whatever actions a pluggable security provider might take at authentication time are going to be based on information from outside the database. It would be nice to have an infrastructure that would support making an access control decision based on data from within the database, but as of today any catalogs consulted during authentication must be (a) shared and (b) nailed, and there's certainly no provision for third-party modules to add shared or nailed system tables (or even, ordinary system tables). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
Stephen Frost writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> FWIW, I am still of the opinion that we shouldn't have a hook here >> anyway, because there is no reason to complain about lack of a >> security context until the user performs an action which requires them >> to have a security context. > I don't agree with this, in general. It may be a difficult problem to > solve though. From my perspective the above is similar to saying we > don't need a pg_hba.conf or that we should open a database before > checking the user's credentials. I'd like to give a security module the > ability to be involved in the initial connection authorization, but we > run into an issue there if that module then needs access to the catalog. Maybe so, but the proposed hook placement doesn't actually allow a plugin module to be "involved" in the authorization --- we've already decided the authorization is OK. All it can do there is some additional initialization, which could equally well be done on first use (if any) of the additional information. There might be some value in letting a plugin actually have some control over the authentication process, but I'm not sure offhand what a reasonable hook design would be. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > 2010/6/16 KaiGai Kohei : > > OK, fair enough. Please wait for a few days. > > I'll introduce the proof-of-concept module until this week. > > I think we have decided not to pursue this, at least for now. If that > is the case, the CommitFest entry should be updated to Returned with > Feedback. I think RwF is fine (since I think we're still waiting on another patch anyway) for this commitfest. I don't want to shut the door entirely on this for 9.1, but a new/updated patch could be done in a later commitfest. > FWIW, I am still of the opinion that we shouldn't have a hook here > anyway, because there is no reason to complain about lack of a > security context until the user performs an action which requires them > to have a security context. I don't agree with this, in general. It may be a difficult problem to solve though. From my perspective the above is similar to saying we don't need a pg_hba.conf or that we should open a database before checking the user's credentials. I'd like to give a security module the ability to be involved in the initial connection authorization, but we run into an issue there if that module then needs access to the catalog. Perhaps it doesn't, but it seems like it would, to use to make a decision. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
2010/6/16 KaiGai Kohei : > OK, fair enough. Please wait for a few days. > I'll introduce the proof-of-concept module until this week. I think we have decided not to pursue this, at least for now. If that is the case, the CommitFest entry should be updated to Returned with Feedback. https://commitfest.postgresql.org/action/patch_view?id=323 FWIW, I am still of the opinion that we shouldn't have a hook here anyway, because there is no reason to complain about lack of a security context until the user performs an action which requires them to have a security context. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/16 21:37), Stephen Frost wrote: > KaiGai, > > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >> On the other hand, a security feature have to identify the client and >> assign an appropriate set of privileges on the session prior to it being >> available for users. > [...] >> However, here is no hooks available for the purpose. > > I believe we understand the issue now, my point was that in the future > let's have this discussion first. > >> One idea is, as Robert suggested, that we can invoke getpeercon() at >> the first call of SELinux module and store it on the local variable. >> It will work well as long as getpeercon() does not cause an error. > > Let's work with this approach to build a proof-of-concept that at least > the DML hook will work as advertised. We've got alot of time till 9.1 > and I think that if we can show that a module exists that implements > SELinux using the DML hook, and that a few other hooks are needed to > address short-comings in that module, adding them won't be a huge issue. > OK, fair enough. Please wait for a few days. I'll introduce the proof-of-concept module until this week. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: > On the other hand, a security feature have to identify the client and > assign an appropriate set of privileges on the session prior to it being > available for users. [...] > However, here is no hooks available for the purpose. I believe we understand the issue now, my point was that in the future let's have this discussion first. > One idea is, as Robert suggested, that we can invoke getpeercon() at > the first call of SELinux module and store it on the local variable. > It will work well as long as getpeercon() does not cause an error. Let's work with this approach to build a proof-of-concept that at least the DML hook will work as advertised. We've got alot of time till 9.1 and I think that if we can show that a module exists that implements SELinux using the DML hook, and that a few other hooks are needed to address short-comings in that module, adding them won't be a huge issue. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/15 21:37), Stephen Frost wrote: > KaiGai, > > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >> In the attached patch, the security hook was moved to ClientAuthentication() >> from InitPostgres(), for more clarification of the purpose. >> What I want to do is to assign additional properties to identify the client >> (such as security label) for each authenticated session. >> >> Its purpose is similar to "session" module of PAM in operating system. >> It allows to assign additional session properties more than user-id. > > That's all fine- but let's work within the confines of the *existing* > hook that's been discussed to get something working first before we go > adding hooks in other places. I think it's important that we put > together at least a proof of concept that an SELinux module or other > external auth module can sensible use the DML hook. > Yes, I'd like to introduce the reason and purpose of the hook. At first, please assume any external security modules should be loaded as shared preload libraries, because 'local_preload_libraries' setting can be overwritten using connection string. So, _PG_init() shall be invoked at the starting-up of the postmaster daemon process at once, not per connection. On the other hand, a security feature have to identify the client and assign an appropriate set of privileges on the session prior to it being available for users. E,g. The default PG security assigns a certain database user-id on the current session, then it will be used for access control decision. In a similar way, an external security also wants a chance to identify, authenticate and authorize the client. (SELinux uses getpeercon() to obtain security label of the peer process, and applies it as privilege of the current session.) However, here is no hooks available for the purpose. In this case, _PG_init() is not called for each connections, because the module is a shared preload library, so we have to call getpeercon() in another point. One idea is, as Robert suggested, that we can invoke getpeercon() at the first call of SELinux module and store it on the local variable. It will work well as long as getpeercon() does not cause an error. Robert pointed out we can always raise ERROR or FATAL using ereport(), if it is troubled. However, it seems to me a trouble of getpeercon() is fundamentally an error within the step of client authentication. In the case of database user-id, it immediately raises an error, and close the connection. I think we should follow the manner of similar features, so I proposed the new security hook at the authentication. Thanks, > After that, we can discuss what other hooks are needed. KaiGai, please, > before sending in patches of any kind, propose at a high-level what the > problem is and what the security module needs in general terms. If you > have a recommendation, that's fine, but let's talk about it before > implementing anything. > > Thanks, > > Stephen -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
On Tue, Jun 15, 2010 at 8:37 AM, Stephen Frost wrote: > KaiGai, > > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >> In the attached patch, the security hook was moved to ClientAuthentication() >> from InitPostgres(), for more clarification of the purpose. >> What I want to do is to assign additional properties to identify the client >> (such as security label) for each authenticated session. >> >> Its purpose is similar to "session" module of PAM in operating system. >> It allows to assign additional session properties more than user-id. > > That's all fine- but let's work within the confines of the *existing* > hook that's been discussed to get something working first before we go > adding hooks in other places. I think it's important that we put > together at least a proof of concept that an SELinux module or other > external auth module can sensible use the DML hook. +1. > After that, we can discuss what other hooks are needed. KaiGai, please, > before sending in patches of any kind, propose at a high-level what the > problem is and what the security module needs in general terms. If you > have a recommendation, that's fine, but let's talk about it before > implementing anything. +2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: > In the attached patch, the security hook was moved to ClientAuthentication() > from InitPostgres(), for more clarification of the purpose. > What I want to do is to assign additional properties to identify the client > (such as security label) for each authenticated session. > > Its purpose is similar to "session" module of PAM in operating system. > It allows to assign additional session properties more than user-id. That's all fine- but let's work within the confines of the *existing* hook that's been discussed to get something working first before we go adding hooks in other places. I think it's important that we put together at least a proof of concept that an SELinux module or other external auth module can sensible use the DML hook. After that, we can discuss what other hooks are needed. KaiGai, please, before sending in patches of any kind, propose at a high-level what the problem is and what the security module needs in general terms. If you have a recommendation, that's fine, but let's talk about it before implementing anything. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/15 12:47), KaiGai Kohei wrote: > (2010/06/15 12:28), Tom Lane wrote: >> KaiGai Kohei writes: >> The attached patch tries to add one more security hook on the >> initialization of PostgreSQL instance (InitPostgres()). >> Yeah, but so what? Stephen's point is still valid. >> >>> On the hook, I'd like to obtain security context of the client process >>> which connected to the PostgreSQL instance. It is not available at the >>> _PG_init() phase, because clients don't connect yet. >> >> InitPostgres is called by a number of process types that don't *have* >> clients. I concur with the other opinions that this hook is badly >> thought out. >> > I intended to skip it when InitPostgres() is called without clients. > > For example, the hook might be better to put on PerformAuthentication() > for more clarification of the purpose. > In the attached patch, the security hook was moved to ClientAuthentication() from InitPostgres(), for more clarification of the purpose. What I want to do is to assign additional properties to identify the client (such as security label) for each authenticated session. Its purpose is similar to "session" module of PAM in operating system. It allows to assign additional session properties more than user-id. Thanks, -- KaiGai Kohei pgsql-v9.1-add-auth-hook.2.patch Description: application/octect-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/15 12:28), Tom Lane wrote: > KaiGai Kohei writes: > The attached patch tries to add one more security hook on the > initialization of PostgreSQL instance (InitPostgres()). > >>> Yeah, but so what? Stephen's point is still valid. > >> On the hook, I'd like to obtain security context of the client process >> which connected to the PostgreSQL instance. It is not available at the >> _PG_init() phase, because clients don't connect yet. > > InitPostgres is called by a number of process types that don't *have* > clients. I concur with the other opinions that this hook is badly > thought out. > I intended to skip it when InitPostgres() is called without clients. For example, the hook might be better to put on PerformAuthentication() for more clarification of the purpose. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
KaiGai Kohei writes: The attached patch tries to add one more security hook on the initialization of PostgreSQL instance (InitPostgres()). >> Yeah, but so what? Stephen's point is still valid. > On the hook, I'd like to obtain security context of the client process > which connected to the PostgreSQL instance. It is not available at the > _PG_init() phase, because clients don't connect yet. InitPostgres is called by a number of process types that don't *have* clients. I concur with the other opinions that this hook is badly thought out. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/15 10:12), Robert Haas wrote: > 2010/6/14 KaiGai Kohei: >> (2010/06/15 9:22), Robert Haas wrote: >>> 2010/6/14 KaiGai Kohei: On the hook, I'd like to obtain security context of the client process which connected to the PostgreSQL instance. It is not available at the _PG_init() phase, because clients don't connect yet. >>> >>> Can't you just call getpeercon() the first time you need the context >>> and cache it in a backend-local variable? Then you don't need a hook >>> at all. >>> >> I've tried to implement my earlier version in this idea. >> As long as getpeercon() performs correctly, it will work well. >> But, if it returns an error due to the system configuration, >> the security module cannot continue to make access control >> decision anymore, although client can open the connection already. >> >> I think this kind of initialization should be also done at >> the initialization of backend, then it disconnect immediately >> if something troubled. > > I think if getpeercon() fails you can just throw ERROR or FATAL at > that point. Until the user does something that requires a valid > security context, there's no reason to terminate the session if they > don't have one. > The 'initialization hook' might be misleading. During authentication steps, the backend raises an error and close the connection immediately, if the backend could not identify the client in the configured way. Because I think security context is a part of identifiers of the user, not only database user id, I proposed a hook on the initialization stage. (Perhaps, it might be placed on just after ClientAuthentication?) I can agree that we can implement the module with this idea, but delayed getpeercon() seemed to me strange. # Of course, it is reasonable if we discuss it later. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
2010/6/14 KaiGai Kohei : > (2010/06/15 9:22), Robert Haas wrote: >> 2010/6/14 KaiGai Kohei: >>> On the hook, I'd like to obtain security context of the client process >>> which connected to the PostgreSQL instance. It is not available at the >>> _PG_init() phase, because clients don't connect yet. >> >> Can't you just call getpeercon() the first time you need the context >> and cache it in a backend-local variable? Then you don't need a hook >> at all. >> > I've tried to implement my earlier version in this idea. > As long as getpeercon() performs correctly, it will work well. > But, if it returns an error due to the system configuration, > the security module cannot continue to make access control > decision anymore, although client can open the connection already. > > I think this kind of initialization should be also done at > the initialization of backend, then it disconnect immediately > if something troubled. I think if getpeercon() fails you can just throw ERROR or FATAL at that point. Until the user does something that requires a valid security context, there's no reason to terminate the session if they don't have one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/15 9:22), Robert Haas wrote: > 2010/6/14 KaiGai Kohei: >> On the hook, I'd like to obtain security context of the client process >> which connected to the PostgreSQL instance. It is not available at the >> _PG_init() phase, because clients don't connect yet. > > Can't you just call getpeercon() the first time you need the context > and cache it in a backend-local variable? Then you don't need a hook > at all. > I've tried to implement my earlier version in this idea. As long as getpeercon() performs correctly, it will work well. But, if it returns an error due to the system configuration, the security module cannot continue to make access control decision anymore, although client can open the connection already. I think this kind of initialization should be also done at the initialization of backend, then it disconnect immediately if something troubled. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
2010/6/14 KaiGai Kohei : > On the hook, I'd like to obtain security context of the client process > which connected to the PostgreSQL instance. It is not available at the > _PG_init() phase, because clients don't connect yet. Can't you just call getpeercon() the first time you need the context and cache it in a backend-local variable? Then you don't need a hook at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/14 21:15), Robert Haas wrote: > 2010/6/14 KaiGai Kohei: >> (2010/06/14 20:01), Stephen Frost wrote: >>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: The attached patch tries to add one more security hook on the initialization of PostgreSQL instance (InitPostgres()). It gives the external security module a chance to initialize itself, and acquire credential of the client. I assumed the best place to initialize the module is just after the initialize_acl() invocation, if ESP is available. We have not discussed about this hook yet. So, I'd like to see any comments. >>> >>> Aren't modules given a __PG_Init or something similar that they can >>> define which will be called when the module is loaded..? >>> >> I assume the security module shall be loaded within >> 'shared_preload_libraries', >> because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting >> using >> connection string, so it allows users to bypass security features, doesn't >> it? > > Yeah, but so what? Stephen's point is still valid. > On the hook, I'd like to obtain security context of the client process which connected to the PostgreSQL instance. It is not available at the _PG_init() phase, because clients don't connect yet. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
2010/6/14 KaiGai Kohei : > (2010/06/14 20:01), Stephen Frost wrote: >> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >>> The attached patch tries to add one more security hook on the >>> initialization of PostgreSQL instance (InitPostgres()). >>> >>> It gives the external security module a chance to initialize itself, >>> and acquire credential of the client. >>> >>> I assumed the best place to initialize the module is just after the >>> initialize_acl() invocation, if ESP is available. >>> We have not discussed about this hook yet. So, I'd like to see any >>> comments. >> >> Aren't modules given a __PG_Init or something similar that they can >> define which will be called when the module is loaded..? >> > I assume the security module shall be loaded within > 'shared_preload_libraries', > because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting using > connection string, so it allows users to bypass security features, doesn't it? Yeah, but so what? Stephen's point is still valid. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
(2010/06/14 20:01), Stephen Frost wrote: > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >> The attached patch tries to add one more security hook on the >> initialization of PostgreSQL instance (InitPostgres()). >> >> It gives the external security module a chance to initialize itself, >> and acquire credential of the client. >> >> I assumed the best place to initialize the module is just after the >> initialize_acl() invocation, if ESP is available. >> We have not discussed about this hook yet. So, I'd like to see any >> comments. > > Aren't modules given a __PG_Init or something similar that they can > define which will be called when the module is loaded..? > I assume the security module shall be loaded within 'shared_preload_libraries', because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting using connection string, so it allows users to bypass security features, doesn't it? Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [v9.1] Add security hook on initialization of instance
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote: > The attached patch tries to add one more security hook on the > initialization of PostgreSQL instance (InitPostgres()). > > It gives the external security module a chance to initialize itself, > and acquire credential of the client. > > I assumed the best place to initialize the module is just after the > initialize_acl() invocation, if ESP is available. > We have not discussed about this hook yet. So, I'd like to see any > comments. Aren't modules given a __PG_Init or something similar that they can define which will be called when the module is loaded..? Stephen signature.asc Description: Digital signature
