On 30/09/15 00:34, Paul Vinkenoog wrote:
> Alex Peshkoff wrote:
>
>> On 09/29/2015 03:23 PM, Dimitry Sibiryakov wrote:
>>> 29.09.2015 13:21, Paul Vinkenoog wrote:
So a CASCADE option would be a welcome addition for such cases.
>>> Another question: how many levels should this cascade go?
Alex Peshkoff wrote:
> On 09/29/2015 03:23 PM, Dimitry Sibiryakov wrote:
> > 29.09.2015 13:21, Paul Vinkenoog wrote:
> >> So a CASCADE option would be a welcome addition for such cases.
> > Another question: how many levels should this cascade go?
> >
> Unlimited, and about it will take care e
Dimitry Sibiryakov wrote:
> 29.09.2015 13:21, Paul Vinkenoog wrote:
> > So a CASCADE option would be a welcome addition for such cases.
>
>Another question: how many levels should this cascade go?
If applied, it should be complete, otherwise it wouldn't be much use. After
all, this is for t
On 09/29/2015 03:23 PM, Dimitry Sibiryakov wrote:
> 29.09.2015 13:21, Paul Vinkenoog wrote:
>> So a CASCADE option would be a welcome addition for such cases.
> Another question: how many levels should this cascade go?
>
Unlimited, and about it will take care existing code - like it already
d
29.09.2015 13:21, Paul Vinkenoog wrote:
> So a CASCADE option would be a welcome addition for such cases.
Another question: how many levels should this cascade go?
--
WBR, SD.
--
Firebird-Devel mailing list, web i
Alex Peshkoff wrote Tue, 29 Sep 2015 14:01:21 +0300:
>
> OK, I agree with such argument.
> So what should be better done:
> 1. Keep it as is
> 2. Add an option to revoke granted by ABC rights too
> ?
>
> --
> Firebird-De
Alex Peshkoff wrote:
> create table t (f int);
> grant select on t to public granted by abc;
> revoke all on all from abc;
>
> Currently privileges, granted by user ABC, remain as is after executing
> mentioned revoke operator. This looks like a bug for me, but befor
2015-09-29 13:38 GMT+03:00 Wols Lists :
> Nothing specific to Firebird, but if ABC is a supervisor who has left
> the company, do you really want to mess up all the people who used to
> work for him?
>
> Or, rather more seriously, if ABC was the DBA, you can't leave him
> there, it's a massive secu
On 09/29/2015 01:38 PM, Wols Lists wrote:
> On 29/09/15 11:20, Alex Peshkoff wrote:
>> On 09/29/2015 01:11 PM, Paul Vinkenoog wrote:
>>> Alex Peshkoff wrote:
>>>
Please look at this trivial sample.
create table t (f int);
grant select on t to public granted by abc;
revoke a
On 29/09/15 11:20, Alex Peshkoff wrote:
> On 09/29/2015 01:11 PM, Paul Vinkenoog wrote:
>> Alex Peshkoff wrote:
>>
>>> Please look at this trivial sample.
>>>
>>> create table t (f int);
>>> grant select on t to public granted by abc;
>>> revoke all on all from abc;
>>>
>>> Currently privileges, gr
On 09/29/2015 01:11 PM, Paul Vinkenoog wrote:
> Alex Peshkoff wrote:
>
>> Please look at this trivial sample.
>>
>> create table t (f int);
>> grant select on t to public granted by abc;
>> revoke all on all from abc;
>>
>> Currently privileges, granted by user ABC, remain as is after executing
>>
Alex Peshkoff wrote:
> Please look at this trivial sample.
>
> create table t (f int);
> grant select on t to public granted by abc;
> revoke all on all from abc;
>
> Currently privileges, granted by user ABC, remain as is after executing
> mentioned revoke operator. This looks like a bug for me,
Please look at this trivial sample.
create table t (f int);
grant select on t to public granted by abc;
revoke all on all from abc;
Currently privileges, granted by user ABC, remain as is after executing
mentioned revoke operator. This looks like a bug for me, but before fixing
(existing SQL op
13 matches
Mail list logo
