Re: Hide source code

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Hide source code
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3415C2D1A@Herge.rcsinc.local
обсуждение исходный текст
Ответ на Hide source code  (Márcio A. Sepp <marcio@zyontecnologia.com.br>)
Список 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, prorettypproacl, 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, prorettypproacl, 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
)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possible better pg_ctl start/stop handling?
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Possible better pg_ctl start/stop handling?