|
The sa_disk_free_space() procedure doesn't change anything, and nobody can possibly argue that the information it returns must be kept secret, so why is DBA authority required to call it in SQL Anywhere 12, and MANAGE ANY DBSPACE privilege required in SQL Anywhere 16? It doesn't "manage" anything, it just reports some numbers that are of vital interest to everyone. |
|
Rightly or wrongly, some argue that knowing how much free space is available on the disk IS a security breach and therefore access to the information is restricted. For example the argument goes like this: if "I" can determine how much disk free space is available at any time then "I" can, through trial and error, try to construct a sequence of operations that will cause the amount of disk space to decrease and hence cause the disk to become full, and therefore "I" can construct a denial-of-service attack on your database server. I'll add that if you don't like the restriction then you can easily create a cover function that is owned by a DBA user that calls the sa_disk_free_space procedure. ... but of course you know that already :-) create procedure "dba".my_disk_free_space( in p_dbspace_name varchar(128) default null ) result( dbspace_name varchar(128), free_space unsigned bigint, total_space unsigned bigint ) begin call "dbo".sa_disk_free_space( p_dbspace_name ); end; grant execute to "dba".my_disk_free_space to public; Wow, so my "suspicion" is officially confirmed - thanks, Mark:)
(19 Mar '13, 16:50)
Volker Barth
|
Hm, to prevent against a possible DOS attack by ordinary/unprivileged users trying to insert data until the (small) free space is occupied, and the server will stop responding? - No, that seems not reasonable...:)
Nice tag, by the way:)
Yes, nice tag... but I'm not sure it helps users find similar or related questions? (FWIW This is the first instance)
No need to worry - I'm sure Breck will add this to his set of favourite tags, i.e. {"debugging", "performance", "even-a-cow-knows"}, so there are more
rantsquestions to come:)