On Sat, Jul 25, 2009 at 5:23 AM, Bill Moran<wmoran@xxxxxxxxxxxxxxxxx> wrote: > Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: >> >> On Fri, Jul 24, 2009 at 5:02 PM, Brian A. >> Seklecki<lavalamp@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> > All: >> > >> > Any suggestions on how-to, or comments on a potential NFR, to disable >> > non-superuser's from viewing the database list via \l? >> >> So, is this a misguided attempt at security through obscurity, or are >> you looking at limiting the noise that users see when they look at >> databases? > > I don't know about misguided, Scott. Security takes many forms. > > If a client wants shared database hosting, but wants an assurance that > other clients using the same shared DB server can't tell who else is > using it? Then they want something other than security. Which isn't necessarily a bad thing, just don't fool yourself into thinking it's security. > It's not security in the strict computer-science definition. Obviously, > if the proper ownerships and grants don't exist to protect the data, in > addition to said obscurity, then the whole thing is pointless. exactly. > But such > obscurity _in_addition_ to proper, real security, has show usefulness > in many areas. Citation needed. I doubt it's ever made any real measurable difference. > Take a properly secured SSH server, for example, and move it to an obscure > port #. Now you've reduced the number of mindless bots looking for > unprotected root accounts, and your IDS solution that monitors the ssh > logs is actually useful. Of course, that's only effective if ssh is > properly secured to begin with. If it's secure, then it doesn't matter what port it's on. If it's not secure, being on a secondary port is no great improvement. > Many clients want the cost-effectiveness of shared DB hosting. Many of > them also want it kept under wraps that they're doing so. The provider > that can do such a thing gets the contract. Those that complain about > "it's not security, it's obscurity" do not get the contract. Yep. And i can guarantee that having such a contract mens you've got a customer that makes you wanna pull your hair out. Having dealt with a few like that in the past. :) But my very serious point on this is that postgresql isnt' designed to hide such things from users, and changing it to do so takes a lot of effort for no real return on investment. OTOH, having a psql client that just uses a different set of queries so that it doesn't show the other dbs could be actually useful and take little or no effort. Given the lack of a serious clarification or answer from OP, I've not been inclined to post anymore on this subject. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
