From 07d75e1b00ab046c839cb131b233e83c59907f2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michal=20=C4=8Ciha=C5=99?= Date: Wed, 27 Jul 2016 17:09:46 +0200 Subject: [PATCH] Clarify documentation on AllowUserDropDatabase MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Michal Čihař --- doc/config.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/config.rst b/doc/config.rst index 88bae2f431..09d8a6f909 100644 --- a/doc/config.rst +++ b/doc/config.rst @@ -1422,18 +1422,21 @@ Generic settings :type: boolean :default: false + .. warning:: + + This is not a security measure as there will be always ways to + circumvent this. If you want to prohibit users from dropping databases, + revoke them corresponding DROP privilege. + Defines whether normal users (non-administrator) are allowed to delete their own database or not. If set as false, the link :guilabel:`Drop Database` will not be shown, and even a ``DROP DATABASE mydatabase`` will be rejected. Quite practical for :term:`ISP` 's with many customers. - .. note:: - - This limitation of :term:`SQL` queries is not - as strict as when using MySQL privileges. This is due to nature of - :term:`SQL` queries which might be quite - complicated. So this choice should be viewed as help to avoid accidental - dropping rather than strict privilege limitation. + This limitation of :term:`SQL` queries is not as strict as when using MySQL + privileges. This is due to nature of :term:`SQL` queries which might be + quite complicated. So this choice should be viewed as help to avoid + accidental dropping rather than strict privilege limitation. .. config:option:: $cfg['Confirm']