Re: Truncate Permission

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Nick Barr <nicky(at)chuckie(dot)co(dot)uk> writes:
> > I was looking to start development on the following TODO entry.
> > Add a separate TRUNCATE permission
>
> Is there actually a use-case for that? It seems like mostly pointless
> complication to me. (Note that in the role world, one can effectively
> have a table owned by a group, so the real issue here is only whether
> there is a point in letting someone truncate a table without having any
> other owner-grade permissions for it.)

Yes, there is a use-case for it. If you don't have triggers or
transactional concerns on the table and you want users to be able to
truncate tables while not allowing them to do things like change the
table structure. I proposed a patch a while ago to implement a seperate
permission for truncate but it was turned down because of concern over
using the few remaining bits in the ACL structure.

My counter-proposal is that the ACLs be split up into two integers
instead of having just one- one for the 'use' bits and a seperate one
for the 'GRANTABLE' bits. This would double the space available for
permission bits and we could support truncate, vacuum, analyze all as
seperate grantable permissions rather than forcing them to be lumped in
with the ownership/ALTER TABLE permissions.

Unfortunately, I havn't had time to actually implement this. I started
on it but all the macros are pretty hard-wired towards the current
implementation and their API isn't suited towards splitting the
GRANTABLE parts out (iirc anyway, it's been a while).

If we could agree on this approach perhaps we could add it as a TODO
with a dependency on it before the seperate TRUNCATE permission is
implemented.

In fact, I brought this up previously in this thread that came up last
year:
http://archives.postgresql.org/pgsql-hackers/2006-04/msg00964.php

Looking back farther, my patch originally added seperate permissions for
TRUNCATE, VACUUM and ANALYZE here:

http://archives.postgresql.org/pgsql-patches/2006-01/msg00028.php

And the concern was about adding too many extra seperate permissions and
about using up too many of the remaining privilege bits. There was an
alternative suggestion to have one bit for
'truncate/vacuum/analyze/whatever-else-we-want' which might be alright
in some cases but I don't like it because it's implied that it could
change over time as we add things and that doesn't really sit very well
with me. Also, it sounds an awful lot like 'almost owner' and I'm not
exactly sure what we'd call it anyway.

With auto-vacuum I'm a bit less concerned about having seperately
grantable 'analyze' and 'vacuum' permissions (though I'd still like) so
perhaps we can agree to use one bit up for a specific 'TRUNCATE'
permission? Doesn't matter to me who implements it, but my patch might
be a decent place to start looking at the areas which have to be
touched. I'd also be happy to update/change it for current HEAD and to
just implement the 'TRUNCATE' permission.

I dunno, given that it's on the TODO and that we've had a patch (at
least in part) for it for over a year, could it get into 8.4? ;)

Thanks,

Stephen