Hi,
> > > > Maybe to keep hostile users from filling up your disk?
>
> Actually, I was serious, not sarcastic, about that "maybe." Like
> Tom, I'm not entirely sure that it's necessary to add this complexity,
> because there are so many other ways to abuse the system.
I know... But we have to st
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Databases have two grantable rights: CREATE allows creating new regular
>> (permanent) schemas within the database, while TEMP allows creation of
>> a temp schema (and thus temp tables).
> Couldn't the temp schema be permanent (an
Tom Lane writes:
[ All the rest looks good to me. ]
> Databases have two grantable rights: CREATE allows creating new regular
> (permanent) schemas within the database, while TEMP allows creation of
> a temp schema (and thus temp tables).
Couldn't the temp schema be permanent (and unremovable),
On Sun, 21 Apr 2002, Sander Steffann wrote:
> At the moment all our DBs are on one partition.
Not really, no. It's easy to put in a symlink to put a database on
another partition. It's easy for any object, for that matter, so long as
it's not the sort of thing that gets deleted and re-created by
On Sat, 20 Apr 2002, Sander Steffann wrote:
> > > Maybe to keep hostile users from filling up your disk?
Actually, I was serious, not sarcastic, about that "maybe." Like
Tom, I'm not entirely sure that it's necessary to add this complexity,
because there are so many other ways to abuse the syste
Hi,
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > On Fri, 19 Apr 2002, Sander Steffann wrote:
> >> I can't think of a reason that [creation of] temp tables should
> >> be prevented.
>
> > Maybe to keep hostile users from filling up your disk?
>
> That does come to mind --- but if you've let host
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Fri, 19 Apr 2002, Sander Steffann wrote:
>> I can't think of a reason that [creation of] temp tables should
>> be prevented.
> Maybe to keep hostile users from filling up your disk?
That does come to mind --- but if you've let hostile users into
your
On Fri, 19 Apr 2002, Sander Steffann wrote:
> I can't think of a reason that [creation of] temp tables should
> be prevented.
Maybe to keep hostile users from filling up your disk?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this n
I said:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> An aclitem[] column on pg_database seems like the most flexible solution
>> to me.
> Yeah, I was afraid you would say that ;-). I'd prefer to avoid it
> because I think we'd need to have a TOAST table for pg_database then.
> And I'm not a
Hi Tom,
> One of the things I'd like this mechanism to do is answer the request
> we've heard so often about preventing users from creating new tables.
> If the DBA revokes write access on the public namespace from a particular
> user, and doesn't create a personal schema for that user, then unde
Tom Lane wrote:
>>This looks good to me. I only wonder if public should default to world
>>read and no create?
>
>
> That would be non-backwards-compatible. Since the main reason for
> having the public namespace at all is backwards compatibility of the
> out-of-the-box behavior, I think we ha
> > Will we be able to accomplish the equivelent of the below?
>
> I think what you're depicting is the equivalent of a schema owner
> dropping a table in his schema, right? Yes, I proposed allowing
that,
Yes, thats what I was looking for. Sorry if I missed that in the
initial proposal.
> > Ye
> That is, of course, a BSD-ism that would confuse a lot of the SysV
people...
> :)
Yup.. But it's been around quite a while and I don't know of any
horrible problems with it -- that said I've not actually tried it on
OpenBSD (different mindset) but would be surprised if it wasn't the
same.
Sur
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Will we be able to accomplish the equivelent of the below?
I think what you're depicting is the equivalent of a schema owner
dropping a table in his schema, right? Yes, I proposed allowing that,
but not granting the schema owner any other ownership righ
> Will we be able to accomplish the equivelent of the below?
>
>
> knight# ls -la
> total 3
> drwxr-xr-x 2 rbt rbt 512 Apr 18 21:53 .
> drwxr-xr-x 43 rbt rbt2048 Apr 18 21:36 ..
> -rwx-- 1 root wheel 0 Apr 18 21:53 file
>
> knight# head /etc/group
> # $FreeBSD: src/etc/gr
> I'm not real comfortable with this. The design I proposed is based
> fairly firmly on the Unix directory/file protection model --- which
> is assuredly not perfect, but it's survived a lot of use and is not
> known to have major flaws. You're suggesting that we should invent
Will we be able t
On Fri, 2002-04-19 at 02:24, Joe Conway wrote:
> I like this general idea and syntax. But it seems awkward to have to
> have the privilege granted twice. What about:
>
> GRANT CREATE SCHEMA [IN { database | ALL }] TO user | PUBLIC
> REVOKE CREATE SCHEMA [IN { database | ALL }] FROM use
Oliver Elphick wrote:
> On Fri, 2002-04-19 at 00:14, Tom Lane wrote:
> I think it could be both: a database owner may not want any schemas
> created by anyone else, or by some particular user; alternatively, the
> administrator may not want a particular user to create any schemas
> anywhere. Thes
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> [ how it ought to be to support hosting companies ]
I'm not real comfortable with this. The design I proposed is based
fairly firmly on the Unix directory/file protection model --- which
is assuredly not perfect, but it's survived a lot of use and is no
> > Another thing that would be needed to prevent users from creating
new
> > tables is to prevent them from creating schemas for themselves. I
am not
> > sure how to handle that --- should the right to create schemas be
treated
> > as a user property (a column of pg_shadow), or should it be
atta
On Fri, 2002-04-19 at 01:10, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> >> Another thing that would be needed to prevent users from creating new
> >> tables is to prevent them from creating schemas for themselves. I am not
> >> sure how to handle that --- should the right
On Fri, 2002-04-19 at 00:14, Tom Lane wrote:
> It's not quite clear what should happen if User A allows User B to create
> an object in a schema owned by A, but then revokes read access on that
> schema from B. Presumably, B can no longer access the object, even though
> he still owns it. A wou
Joe Conway <[EMAIL PROTECTED]> writes:
> If user1, the owner of the schema1, creates a new table tab1, will user2
> who has "Read" privilege to schema1, be automatically granted SELECT
> privilege on tab1? Or will he be able to see that tab1 exists, but not
> select from it (continuing the an
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> We'll define two privilege bits for namespaces/schemas: "read" and
>> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
>> choices).
> I think other databases actually use GRANT CREATE.
Okay, I'm not picky about the keywords.
>
Tom Lane wrote:
> We'll define two privilege bits for namespaces/schemas: "read" and
> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
> choices). "Read" controls the ability to look up objects within
> that namespace --- it's similar to "execute" permission on directories
>
Tom Lane writes:
> We'll define two privilege bits for namespaces/schemas: "read" and
> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
> choices). "Read" controls the ability to look up objects within
> that namespace --- it's similar to "execute" permission on directories
"Rod Taylor" <[EMAIL PROTECTED]> writes:
>> Should the owner of a database (assume he's not a superuser) have the
>> right to drop any schema in his database, even if he doesn't own it?
>> I can see arguments either way on that one.
> Given that you've chosen to allow the owner of a schema or the
> Should the owner of a database (assume he's not a superuser) have
the
> right to drop any schema in his database, even if he doesn't own it?
> I can see arguments either way on that one.
Given that you've chosen to allow the owner of a schema or the table
to drop a table, it would be consistent
I've been thinking about exactly what to do with access privileges for
namespaces (a/k/a schemas). The SQL99 spec isn't much guidance, since
as far as I can tell it doesn't have explicit privileges for schemas
at all --- and in any case, since it identifies schemas and ownership,
the really inter
29 matches
Mail list logo
