SEO

> > In an ideal world, if a user can't modify a function, he/she shouldn't
> be
> > able to see the source code. If the user can execute the function, then
> the
> > user should be able to see the signature of the function but not the
> body.
>
> I doubt that's going to happen. Mainly because I disagree completely
> with your ideal world description (any user who can execute a function
> should have the right to examine it to see what it actually does).
>

That is like saying anyone that has rights to call a web service should be
able to see the source code for it. There should be the ability to create
some level of abstraction when appropriate.

However, in the current configuration, all users with permission to log in
can see all source code. They don't have rights to execute the functions
but they can see the source code for them. Shouldn't I be able to revoke
both the ability to execute and the ability to see functions?


Jon

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

In response to "Roberts, Jon" <Jon.Roberts@asurion.com>:

> > > In an ideal world, if a user can't modify a function, he/she shouldn't
> > be
> > > able to see the source code. If the user can execute the function, then
> > the
> > > user should be able to see the signature of the function but not the
> > body.
> >
> > I doubt that's going to happen. Mainly because I disagree completely
> > with your ideal world description (any user who can execute a function
> > should have the right to examine it to see what it actually does).
>
> That is like saying anyone that has rights to call a web service should be
> able to see the source code for it.

I think that's a good idea. If vendors were forced publish their code,
we'd have less boneheaded security breaches.

> There should be the ability to create
> some level of abstraction when appropriate.

I agree. If vendors want to have boneheaded security breaches, they should
be allowed.

> However, in the current configuration, all users with permission to log in
> can see all source code. They don't have rights to execute the functions
> but they can see the source code for them. Shouldn't I be able to revoke
> both the ability to execute and the ability to see functions?

Um ... why did you snip my second paragraph where I said exactly this?

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Joshua D. Drake wrote:

> > > However, in the current configuration, all users with permission to
> > > log in can see all source code. They don't have rights to execute
> > > the functions but they can see the source code for them. Shouldn't
> > > I be able to revoke both the ability to execute and the ability to
> > > see functions?
>
> Yes and know. If your functions are interpreted then no, I don't see
> any reason for this feature, e.g; python,perl,plpgsql,sql,ruby. I can
> read them on disk anyway.

If you have access to the files, which is not necessarily the case.
Random users, in particular, won't.

Maybe this can be done by revoking privileges to pg_proc. I am sure it
can be made to work. It does work for pg_auth_id, and nobody says that
"they can read the passwords from disk anyway."

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"We're here to devour each other alive" (Hobbes)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

In response to "Joshua D. Drake" <jd@commandprompt.com>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 14 Dec 2007 11:18:49 -0500
> Bill Moran <wmoran@collaborativefusion.com> wrote:
>
> > > That is like saying anyone that has rights to call a web service
> > > should be able to see the source code for it.
> >
> > I think that's a good idea. If vendors were forced publish their
> > code, we'd have less boneheaded security breaches.
>
> Not all closed source code is subject to boneheaded security breaches.
> I believe that this individuals request is a valid one from a business
> requirements perspective.

I could go into all sorts of philosophical debates on this ... for example,
"not all drivers are stupid enough to ram their cars into other things,
yet we still have seatbelt laws in the US."

> > > There should be the ability to create
> > > some level of abstraction when appropriate.
> >
> > I agree. If vendors want to have boneheaded security breaches, they
> > should be allowed.
>
> It is not up to your or me to make the determination of what people are
> able to do with their code.

That's what I said. Despite my cynical nature, I _do_ believe in
allowing people to shoot their own foot. Sometimes it's funny to
watch.

Any, yes, there are some folks who have very good QA and documentation
teams and can avoid pitfalls of security breaches and poorly documented
functions with unexpected side-effects. Even if they're not that
brilliant, they deserve the right to make their own choices.

> > > However, in the current configuration, all users with permission to
> > > log in can see all source code. They don't have rights to execute
> > > the functions but they can see the source code for them. Shouldn't
> > > I be able to revoke both the ability to execute and the ability to
> > > see functions?
>
> Yes and know. If your functions are interpreted then no, I don't see
> any reason for this feature, e.g; python,perl,plpgsql,sql,ruby. I can
> read them on disk anyway.

I disagree here. If they're connecting remotely to PG, they have no
direct access to the disk.

> If you want to obfuscate your code I suggest you use a compilable form
> or a code obfuscation module for your functions (which can be had for
> at least python, I am sure others as well).

Although this is an excellent suggestion as well.

But I still think the feature is potentially useful.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Dec 14, 2007 2:03 PM, Bill Moran <wmoran@collaborativefusion.com> wrote:
> I disagree here. If they're connecting remotely to PG, they have no
> direct access to the disk.

pg_read_file?

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly