Re: Hide source code

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "David Fetter" <david(at)fetter(dot)org>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hide source code
Date: 2005-07-11 18:06:03
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3415C2D1A@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, Jul 11, 2005 at 07:59:44AM -0400, Merlin Moncure wrote:
> Interesting. Again, this is pretty fragile with respect to, for
> example, pg_dump(all).

No, it isn't. If you revoke permission on pg_proc, /df in psql will
fail, as will pg_dump. Try it (you have to revoke all on pg_proc form
public).
See the log below:

C:\svn\rcsi\Etc>pg_dump -U test xxx
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: permission denied for
relation pg_proc
pg_dump: The command was: SELECT tableoid, oid, proname, prolang,
pronargs, proargtypes, prorettyp
proacl, pronamespace, (select usename from pg_user where proowner =
usesysid) as usename FROM pg_
oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace
where nspname = 'pg_catalo
)

> > Regardless of your philosophical standpoint, many larger
> > organizations will feel uncomfortable with having unprivileged users
> > having access to all the database procedure source code.
>
> That some "larger organizations" choose to use the known-unsafe method
> of security by obscurity is not a reason for anybody here to expend
> any effort helping them persist in this illusion: quite the opposite,
> in fact. "Larger organizations" are likely to have security needs
> which they actually need to address, not to pretend they've addressed
> while actually making things easy for attackers.

I think you are confusing 'security by obscurity' with 'security by
policy'. The reasons for not allowing non-privileged users within your
company access to your source codes are highly nuanced. Generally,
though, on the systems I admin information is doled out on a 'need to
know' basis. The data in the database is managed in a highly controlled
fashion, why not the code?

Non technical users have no business looking at the code I write because
their bosses (not me) prefer it that way. End of story.

observe:
C:\svn\rcsi\Etc>pg_dump -U test xxx
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: permission denied for
relation pg_proc
pg_dump: The command was: SELECT tableoid, oid, proname, prolang,
pronargs, proargtypes, prorettyp
proacl, pronamespace, (select usename from pg_user where proowner =
usesysid) as usename FROM pg_
oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace
where nspname = 'pg_catalo
)

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2005-07-11 18:34:07 Re: Possible better pg_ctl start/stop handling?
Previous Message Tom Lane 2005-07-11 17:50:14 Re: Possible better pg_ctl start/stop handling?