[Babase] creating tables in sandbox
kfenn
kfenn at princeton.edu
Fri Oct 19 14:08:26 EDT 2007
Thanks, Karl. I understand and agree with the security and
clean/controlled sandbox issues. The extra step of having to go through
an administrator will keep things tidy in there.
Given this information, I think in cases where there is an exchange of
tables between two individuals only, I will have them deal directly with
one another and not leave something in the sandbox. However, when a
table may need to be used and accessed multiple times by multiple people
(as we will be doing for our current senior undergrads), using the
sandbox is probably best.
Lacey, any additional thoughts on this? We should probably keep some
sort of simple log (maybe on the wiki) anytime we allow new tables into
the sandbox. This will give us some guidelines for deleting tables
after they have served their purpose.
Obviously we can discuss this later when we both aren't so busy.
Tabby
Karl O. Pinc wrote:
> Ugh. Sorry for the delay.
>
> On 10/17/2007 09:41:06 AM, kfenn wrote:
>> Hi Karl,
>>
>> Laurence and I need to exchange some tables build from queries tables
>> with undergrads. These undergrads have their own schemas and are
>> babase users. Laurence has tried to put tables into the sandbox but
>> she can't because babase_readers aren't allowed to create in the
>> sandbox. Is there a reason the privileges were set this way?
>
> The idea was that the babase_editors would have control over
> the sandbox so that we always knew what was in it, so that it did
> not grow out of control. So, you guys would create tables in
> the sandbox and grant privileges on an as-needed basis, either
> to particular users or to groups.
> For this to work the user needs to grant you (or better yet,
> the babase_editors group) SELECT privileges to the particular
> table they want moved into the sandbox schema.
> (GRANT SELECT ON TABLE foo TO babase_editors;)
> Then you can do a SELECT INTO to move the table and it's contents
> into the sandbox schema.
>
> The user's going to have to do a GRANT anyway, because otherwise
> only the user who creates the table will be able to use it.
> (For that reason after you move the table into the sandbox
> you'll need to grant appropriate permissions, but the theory is
> that you know more about who should have what permissions than
> the regular users do.)
>
> Security is a pain, but is better than no security.
>
>>
>> I talked to Lacey about this. We thought the sandbox was a place to
>> exchange information so any babase user should be able to create a
>> table in the sandbox and export a table from the sandbox to their own
>> schema for further manipulation. Is this correct and can we change
>> the privileges to make this happen?
>
> We can change it. I'd still be worried that cruft would accumulate
> until we don't know what's what and we can't get rid of anything.
> (See the temp directory in foxpro.)
>
>>
>> Also is there a way to set editing priviledges in the sandbox, or can
>> we only specify CREATE and USAGE...?
>
> Read and write privileges must be granted on a per-table basis.
> http://www.postgresql.org/docs/8.1/static/sql-grant.html
>
> Karl <kop at meme.com>
> Free Software: "You don't pay back, you pay forward."
> -- Robert A. Heinlein
>
> _______________________________________________
> Babase mailing list
> Babase at www.eco.princeton.edu
> http://www.eco.princeton.edu/mailman/listinfo/babase
--
Tabby Fenn
Research Assistant
Dept of Ecology and Evolutionary Biology
401 Guyot Hall
Princeton University
Princeton, NJ 08544
609 258-6898 (Ph)
609 258-2712 (Fx)
More information about the Babase
mailing list