This is my own view, but it comes from a conversation with Dmitry:

- Rights on sys tables should be forbidden. If you want to grant/revoke
specific actions, use DDL. No ACLs on sys tables.
- If there are things that can't be accomplished with our regular methods,
we create more DDL. We should teach users to not rely on undocumented
behavior. For example, if someone needs to write to rdb$files directly
because there's no DDL, then we create the DDL to allow the change under
controlled environment but don't allow the direct writing.
- Using ATT_gbak_attachment is a security risk, but I don't know how to
solve it. I think this should be replaced by a role, BACKUP_OPERATOR and of
course, this role is checked against the active user, not a program saying
"I'm gbak". Anybody pretending to be gbak can screw sys tables or read more
data than desired.
- Creating user objects with RDB$ prefix should be forbidden (at least until
we implement schemas).
- Using system domains in user tables should be forbidden.
- Linking user tables to sys tables (FK) should be forbidden (I didn't try,
but if it works, it shouldn't).
- User code should not fiddle with sys generators (I think Dmitry achieved
that with ACLs on generators).
- Taking exclusive lock on sys tables from DML should be forbidden, except
for sysdba:
select * from <sys_table> for update with lock;  => disaster?
Of course, we should check all options in the TPB, too.

Probably, the super user should be given the possibility of messing
everything at will if it activates a flag. From this POV, checking rights in
code is (for me) more flexible than a set of ACLs for sys tables.

Comments?

C.
---
Claudio Valderrama C.
Consultant, SW developer.


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to