On Wed, Sep 30, 2009 at 1:09 PM, DrunkenMonk <[email protected]> wrote:
>
>> P.S. Just a thought, but shouldn't you have some kind of confirmation
>> before executing an msql command with the potential to delete your
>> entire site? And have you gotten stamp functionality to work, or just
>> using the default stamps system. Just curious as the though of system
>> wide incineration comes to mind. :)
>
> Any query I don't have control over could potentially drop the entire
> database, assuming the mysql user has privileges to do this. In order
> to prevent this, I disallow myql users (the users on the mysql server)
> based on pages, which means any query with sufficient rights to damage
> the system is limited to site-pages or similar places.
Not sure I follow this. How does your mysql function know which mysql
user is calling the function? Are they a parameter in the function?
Parallel to the $BOLTid? And you have different rights for different
kinds of querys? Like read data, vs store data, vs delete records or
whole tables? Sound a bit complex... The picture is not clear to me
(pardon my denseness). I'm hesitant to make a fix without
understanding exactly what you need.
>> A quick check suggests this would interfere with how auth works for
>> specific functions/commands. Which I never use, and I'm not sure
>> anyone else does.
>
> Well, yes. Because this would have the same problem. Imagine a
> dangerous command (for example, "spam the internet" or "delete
> everything") which you wish to restrict to certain pages on
> boltwire.com. Imagine me wanting to make a point, and put this command
> somewhere in boltwire.com where I have write access. I now link to
> this page here,and you follow the link. I've caused you to execute the
> command as a super-user.
Ok, I see your point, and unfortunately you are right. A user could
post a mail function in a comment box for example, and then when I go
read the comment, I've just fired off an email. Do you have a
recommendation?
>> But it is a good feature, I don't want to drop.
>
> This made me pause. Why is it a good feature? I've always assumed it
> was, but... building a tool that requires super user administration to
> function is not a good thing no matter how I look at it. Super admin
> priviliges are needed in order to access and write to pages. Anything
> else is just making debugging harder for me.
This should not be causing you problems unless you are using them,
unless you mean it gave me pause before changing the BOLTauth
function. But as for why it might be important: suppose I want to
limit functions available in a comment box (forum*). It would be great
to say
forum*: breadcrumb,time,misc_other_safe_ones
And know that section of my site is safe from BoltWire savvy
commenters. On the other hand, the current implementation does not
provide that protection as intended, because an admin might accidently
stop in and trigger something malicious posted by another user
unauthorized to execute it himself.
> Anyway, I'm not suggesting you drop the functionality, but I do think
> being able to be dupped into bypassing security is a serious concern,
> so propose that the system is not much use right now.
Agreed. The question is what is the best solution. I propose this:
Add an $admin parameter to BOLTauth that can be turned off for auth
checks where you want to ignore super admin status. Then check that
parameter before approving an auth request based on their super admin
status.
This way, when checking auth for a potential site.auth.function,
site.auth.command, or of course, site.auth.msql page, I simply add
false as the 4th parameter. In engine.php this involves lines 806 and
2x in line 926
I've noticed in every other case $BOLTid is used for the $find,
meaning $BOLTid could be changed to $find with no problem. Though it
no longer causes you the problem you are currently having so it may
not be critical.
So you end up with this:
function BOLTauth($check, $find, $type, $admin=true) {
...
if ($admin) {
if (strpos(" ,$BOLTadmin,", ",$find,") && $BOLTadmin != '')
return true;
}
What do you think about this possibility? Would it meet your needs? It
seems to solve the problems you pointed out above. I've added this to
my source code for the next release unless it doesn't work for you, or
you see some problem with it.
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
