Database permissions - new SMF 2.0.15 install

[dubob4432]

I have read that the db username needs the following permission for that db user - SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, and INDEX.  The actual full sentence, from the main SMF install instructions states:
"The database user requires the following permissions: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, and INDEX. Additional permissions may be granted, if desired."

What additional permission could/should be selected and what would their benefit be?

Thanks,
Bob

[Aleksi "Lex" Kilpinen]

Those are the permissions an unaltered "vanilla" SMF can function with.
It does not need any more, but then again there is no harm in it (from SMF's point of view) if the user has full privileges to the DB.

I don't really know how to better answer that at this point.

[shawnb61]

Hmmm...  I think that list is out of date.  Based on this post here:
   https://www.simplemachines.org/community/index.php?topic=560554.msg3974099#msg3974099
...it looks like we need CREATE TEMPORARY TABLES as also to operate SMF.

The other privileges (mainly VIEW, LOCK & ROUTINE related) would only be needed if you use that user for other non-SMF functions. 

[Illori]

i think that is only for SMF 2.1, not SMF 2.0, either way the page should be updated.

[shawnb61]

I think you're right...  I spend so much time in the 2.1 world they're starting to blur...   

[dubob4432]

Appreciate the info.  Is there any vulnerability in giving the smf username full accesss?  I would like to give the least amount of permission as possible 'just in case', but I do not want to cripple my forum install.  FWIW, I will be using the 2.0.x fork.

Thanks,
Bob

Edit - This will be a 'vanilla' install, for the most part, but I would like to mess around with different types of sign up add-ons as on a 'production' smf forum that has been running for about 10yrs, in the last couple of months we have had an incredible amount of fake sign up attempts - literally about 5000/month, and this is a specialized niche type of forum, so 5000/mo is ridiculously off the charts, so for the mean time we have no allowed new sign ups until I can get this test forum running and find a decent add-on.

[shawnb61]

The set doc'd above includes all the most dangerous ones already - DROP, DELETE, UPDATE, ALTER, etc. 

I.e., I'm not sure you are actually any safer by excluding VIEW-related & the other ancillary functions. 

So I don't think there is any additional vulnerability by providing full access.  Either way, if a bad actor has that access & those credentials, you're in trouble. 

[dubob4432]

The set doc'd above includes all the most dangerous ones already - DROP, DELETE, UPDATE, ALTER, etc. 

I.e., I'm not sure you are actually any safer by excluding VIEW-related & the other ancillary functions. 

So I don't think there is any additional vulnerability by providing full access.  Either way, if a bad actor has that access & those credentials, you're in trouble. 

Gotcha!  Thanks