Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost <sfr...@snowman.net> wrote: > > I don't exactly see how an extension or contrib module is going to be > > able to have a reasonable catalog structure which avoids the risk that > > renaming an object (role, schema, table, column, policy) will break the > > configuration without being part of core. > > At some level, I guess that's true, but a custom GUC would get you > per-role and per-database and a custom reloption could take it > further. A security label provider specifically for auditing can > already associate custom metadata with just about any SQL-visible > object in the system.
Ugh. Yes, we could implement a lot of things using per-object GUCs and reloptions. We could do the same for columns with custom attoptions. For my part, that design looks absolutely horrible to me for more-or-less everything. I certainly don't feel like it's the solution which extension authors are looking for and will be happy with, nor do I feel it's the right answer for our users. > > Add on to that the desire for > > audit control to be a grant'able right along the lines of: > > > > GRANT AUDIT ON TABLE x TO audit_role; > > > > which allows a user who is not the table owner or a superuser to manage > > the auditing. > > As Tom would say, I think you just moved the goalposts into the next > county. I don't know off-hand what that syntax is supposed to allow, > and I don't think it's necessary for pgaudit to implement that (or > anything else that you may want) in order to be a viable facility. Perhaps I should have used the same argument on the RLS thread.. Instead, I realized that you and others were right- we don't want to implement and commit something which would make adding the features being asked for very difficult to do in the future. The point of the command above is to allow a role *other* than the table owner to control the auditing on the table. It's important in certain places that the auditor have the ability to control the auditing and *only* the auditing- not drop the table or change its definition. I'm also not asking for this to be implemented today in pgaudit but rather to point out that we should have a design which at least allows us to get to the point where these features can be added. Perhaps there's a path to allowing the control I'm suggesting here with the existing pgaudit design and with pgaudit as an extension- if so, please speak up and outline it sufficiently that we can understand that path and know that we're not putting ourselves into a situation where we won't be able to support that flexibility. > > For my part, I do view auditing as being a requirement we should be > > addressing through core- and not just for the reasons mentioned above. > > We might be able to manage all of the above through an extension, > > however, as we continue to add capabilities and features, new types and > > methods, ways to extend the system, and more, auditing needs to keep > > pace and be considered a core feature as much as the GRANT system is. > > I think the fact that pgaudit does X and you think it should do Y is a > perfect example of why we're nowhere close to being ready to push > anything into core. We may very well want to do that someday, but not > yet. That's fine- but don't push something in which will make it difficult to add these capabilities later (and, to be clear, I'm not asking out of pipe dreams and wishes but rather after having very specific discussions with users and reviewing documents like NIST 800-53, which is publically available for anyone to peruse). Thanks, Stephen
Description: Digital signature