Without this, I don’t really see the point in confirmation before downloading a backup: Assuming an attacker hijacked an admin’s session, couldn’t he simply sign up a new account with an email address he controls, grant admin privileges to that user, and then use that user to download the backup?
He’s shown a message saying We’ve sent you an email to confirm this action. Please click the link inside this email to grant administrative privileges to @username.
He gets an email, clicks the link in it, goes through a JavaScript-button to prevent accidental “clicks” (just as with the activation link), and boom, @username has admin privileges
I basically implemented it as you suggested, except there is no Javascript button as we do for account activation. That was meant to prevent bots from signing up and I don’t think it’s necessary in this case. It still shows you a HTML form with a button though to prevent email clients from crawling emails and activating the admin though.
I’m curious about the rationale of this change. What does adding additional steps, which require external dependencies (email) actually accomplish here?
Case in point: We have a dev server with problems getting emails out. Trying to add an admin account to do troubleshooting, but I can’t do so because adding an admin requires email be working.
Doesn’t someone signed in as an admin user already have full access to the site’s configuration & content, and control over all user accounts?
If the above answer is yes, I guess I’m still not sure what security benefit is achieved by sticking email in the middle of the process. I may certainly be missing something though…
How about creating a second database role for the Data Explorer?
grant select on #{database} to discourse_data_explorer;
revoke select password_hash, auth_token on users from discourse_data_explorer;
# repeat for other sensitive columns
#in data explorer execute:
Begin;
Set read only blah blah;
Set local role discourse_data_explorer;
(Note that this doesn’t actually work, revokes undo grants and can’t carve out of them)
OK, I understand it from a security/engineering perspective as some type of hypothetical ideal, but my comments reflect an actual user telling y’all that the UX is very bad for folks trying to migrate sites between servers.
We disable email when doing migrations so notifications don’t go out inadvertently. These changes that require email to be enabled (a third-party dependencies to be working!) make it difficult-to-impossible for adding users or dealing with backups during that time, not to mention make it impossible to get your site out of a “broken email” scenario.
Now pardon me while I go back to pulling my hair out…
